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 à 08:53 -0700, Travis Reitter a écrit : > 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 > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list