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

[Xavier Claessens <xclaesse gmail com>]

I didn't had time to read the full discussion, here is my vision of what
should be done for contact managing in the GNOME desktop
(freedesktop ?).

We need a daemon that get information about contacts from Mission
Control accounts and store it locally somewhere. Actually that job is
done by eds-sync (which is not part of empathy), it takes all contacts
it sees in any telepathy account, request information like avatar/alias
and put those information into eds. If the X-Jabber and X-MSN VCard
fields are filled in an evolution contact it can merge information from
the msn and jabber telepathy contact into one single eds contact.

My plan was to use eds contacts filled by eds-sync in empathy, like that
eds-sync makes the merging job for me and I just get one contact object
per real person and not per telepathy account.

I agree we need some remote storing because the user will fill X-Jabber
and X-MSN fields and don't want that to be lost, and want to sync that
with other desktops or devices like N800. I also agree that eds does not
completely fits all our needs. We have the choice of improving eds a bit
or building our new API which is called online-desktop-engine if I
understand correctly.

I think libempathy is not the right place to do all that magic. Empathy
is about IM, not a complete contact book managing. We can do all that
magic outside empathy (like eds-sync actually does) and empathy can just
get the contact list from online-desktop-engine instead of from
telepathy. The only thing empathy needs is some mapping between
ode-contact (ode=online desktop engine) and telepathy handle. One
ode-contact can have many telepathy handles so we need an api like

guint ode_contact_get_jabber_tp_handle(OdeContact*);

using empathy, the user should be able to say: "that 2 contacts are the
same real person" so we need an api to tell ode to merge information
from 2 contacts both contacts can already represent many telepathy
contacts. So we need:

OdeContact* ode_merge_contacts (OdeContact*, OdeContact*);

I see ODE as a central API to access information about all contacts. If
we make that new API we need to port evolution to use that API too, like
that evolution can make things like:

empathy_new_chat_with_contact (OdeContact*)

to reply to an email by IM.

and ODE will take care of uploading all information in a remote server
to let the user sync adresse book in all kind of devices/desktops.

That's my point of view.

Xavier Claessens.

Le jeudi 26 juillet 2007 �8:53 -0700, Travis Reitter a �it : 
> On Wed, 2007-07-25 at 15:42 -0400, Owen Taylor wrote:
> 
> <snip>
> 
> > 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
> lowest-common-denominator.
> 
> 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).
> 
> -Travis
>