Re: Online Desktop/People apps (short-term)
- From: Owen Taylor <otaylor redhat com>
- To: Travis Reitter <treitter-dev netdrain com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Online Desktop/People apps (short-term)
- Date: Wed, 25 Jul 2007 15:42:32 -0400
On Tue, 2007-07-24 at 22:27 -0700, Travis Reitter wrote:
> At GUADEC, a number of the people-centric software people (from Soylent,
> Banter, Empathy, Telepathy, Mugshot/Online Desktop) got together to
> discuss some issues around integrating our work.
> Here are some ideas for the short-term implementation, to get us rolling
> on integration. Many of these based on other peoples' ideas, but here's
> how I think it can all fit together. This isn't exhaustive, and mainly
> focuses on issues related to people-centric apps.
I'm going to respond a little out of order here. First I want to point
out the things that I really agree with:
> [...]. I think, and I believe we
> largely agreed in the discussion, that we care mainly about the use
> cases with intermittent network connectivity as opposed to use cases of
> rare network connectivity. If you rarely have an Internet connection,
> the Online Desktop won't be very interesting to you.
Exactly ... we shouldn't think about synchronizing your machine's
addressbook with some other addressbook, we should think of it more like
IMAP where you may have some ability to do things offline, but it's
clear that you are editing the online copy.
> As much as possible, I would like to avoid manual metadata entry. The
> social networking model works very well for this. That way, you fill out
> your own details once, mutually connect with people, and that's it. Each
> time your friends update their profiles, your address book is updated
> automatically. This substantially beats the old desktop equivalent,
> where you have to manually enter and synchronize your contacts' full
> profiles on each of your devices.
This too - I don't think people interact with addressbook interfaces
much at all these days ... if you send email to somebody, your email
program remembers it. If someone you meet gives you their facebook
info, do you go and add it to an addressbook? No, you make a note
of it, and next time you are online, you go to facebook and add them
as a friend. Centering an interface around data entry for other people
doesn't make much sense.
So, I think I agree a lot with the basic premises here. But when
I look at:
> Basic Architecture
> [Desktop People Apps] <-> [Empathy] <-> [e-d-s] <->
> [Online desktop server]
That just doesn't make a lot of sense to me. What the Empathy block
here is doing here is merging together data from various sources; not
just e-d-s, but also Telepathy, Pidgin, or whatever. I see the
online-desktop-server as another of those sources. As such, is there
any reason to force it into the VCard mold?
I imagine a model more like:
[ Empathy ]
/ / \ \
/ / \ \
/ / \ \
[Telepathy] [e-d-s] [Facebook] [[online-desktop-engine]]
(Utter and total ascii art failure...)
Note that the online-desktop component is in fact privileged since it's
our primary source of information about how to do the merge and it's
also where "edits" of the merge (the user asserts that two people are
the same thing) get stored.
You can then imagine that there is a simplified version in the case
where the user hasn't configured an online desktop server where e-d-s
takes on that privileged role.
But that doesn't mean to me that e-d-s and the online-desktop-engine
are the same thing... we just have a big switch for the merge engine
between the two modes.
One open question my mind is whether the merging of people really should
be an separate entity, or whether it's just part of the
online-desktop-engine, so the picture:
(generic data model API)
/ / \ \
/ / \ \
/ / \ \
[Telepathy] [e-d-s] [Facebook] [online-desktop-server]
So, that's my big picture of the situation: We don't try to wedge extra
functionality into e-d-s ... we just leave it as it currently is - a
VCard store. Then we build the new world of people with dynamic merging
using that as one more data source, as necessary.
] [Thread Prev