Re: Online Desktop/People apps (short-term)

On Wed, 2007-07-25 at 15:42 -0400, Owen Taylor wrote:


> 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?

VCard itself is kind of a pain, but the upshot is that it's a fairly
standard address book entry format. Though I've heard that most
implementations abuse its extensibility, so it ends up going down to the

But thinking about things in a more social network sense, again, you're
right - if we want to pass along someone's contact information, we
should just pass along a Mugshot/Online Desktop ID. Then the person
getting the contact information is ensured it stays up-to-date, and the
person whose information you're passing even has the option to deny it,
which is another benefit.

> I imagine a model more like:
>            [Desktop Apps]
>                  | 
>        [      Empathy       ]
>        /       /   \        \
>       /       /     \        \
>      /       /       \        \
> [Telepathy] [e-d-s] [Facebook] [[online-desktop-engine]]
>                                         |
>                               [online-desktop-server]
> (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.

So, say you edit your personal information in About Me. Does that mean
that it would send the changes to libempathy, and libempathy would
filter and mangle and send along the changes as appropriate for e-d-s,
Facebook, o-d-e, etc.?

That sounds good, since it should be possible to handle new and
different sources via plugins. It largely pushes logic and work from
e-d-s into libempathy - which isn't necessarily a bad thing, given the
flexibility/ease-of-upstreaming-changes in libempathy vs e-d-s.

> 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.
>     [Desktop Apps]
>          | 
>       [Empathy]
>      /         \
>     /           \
>    /             \
> [Telepathy]   [[e-d-s]]
> 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:
>            [Desktop Apps]
>                  |
>          (generic data model API)
>                  | 
>        [[online-desktop-engine]]
>        /       /   \        \
>       /       /     \        \
>      /       /       \        \
> [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.

That also sounds good. I am a little concerned about pushing this all
into libempathy without hearing what Xavier (the maintainer, cc'd)
thinks. Right now libempathy is just for handling IM (contacts,
accounts, and starting conversations, etc.), though Xavier has expressed
interest at least in adding e-d-s support. If he thinks it would be
better to keep libempathy more focused, we could use this second model
and start working on the online-desktop-engine, using libempathy as a
starting point for a plug-in system (to handle Telepathy communication).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]