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

[Travis Reitter <treitter-dev netdrain com>]

On Thu, 2007-07-26 at 12:18 -0400, Owen Taylor wrote:
> On Thu, 2007-07-26 at 08:53 -0700, Travis Reitter wrote:
> > 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.
> 
> What bothers me about trying to use VCard for editing is that it seems
> very forced if the UI we are working with isn't an address-book style
> interface.

I was just thinking of it in terms of storage in retrieval. I doubt we'd
want to just cram more and more editing capability into Evolution's
address book UI (especially under the current model, where all the
fields get dedicated widgets, whether they're filled in or not).

> Say that we want to allow dragging two people together to
> assert that your friend owtaylor on Myspace is the same as
> otaylor redhat com  How do you represent that via VCard? Do you create a
> VCard with a standard email attribute, and an "extended" Myspace
> attribute, and insert it in the user's address book? What does that look
> like if the user actually goes to their address book in evolution?

Yeah, anything outside of standard fields would be an extended attribute
(all non-generic website metadata, like URLs and usernames fit into this
category).

Evolution ignores any VCard fields it doesn't know how to handle (which
I think in some ways is a good thing - that way you could import vcards
from another source without data loss, in case you wanted to export back
to it). Of course, since the UI ignores the fields, it means you can't
edit fields you may care about (not within Evolution's UI, at least).

> > > 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.
> 
> In general, I don't think you want to do that kind of "edit one place,
> change multiple things" ... they won't map together perfectly, and
> things can just get weird. If someone is keeping there information
> up-to-date in Facebook, then why do we need About Me?

Any social network will certainly have special fields no generic
addressbook app would know or care about (eg, I think Facebook has
something like "What I've been doing lately"). But I certainly would
like a central place to set the common things, like my name, email
addresses, screen names, etc., without having to manually set those on
each service. And those all seem to be standard VCard fields. I'm not
dead-set on using VCard for common attributes, but it just seems like
that's already handled by anything trying to use standards.

> (Bryan had some comments about that in the blog entry he posted
> yesterday: http://clarkbw.net/blog/2007/07/25/online-gnome-dot-org/)
> 
> But when we do want to do updates, it certainly is easier if we
> don't have the e-d-s abstraction in the way.
> 
> > > 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).
> 
> I actually temporarily forgot what Empathy was when writing my reply;
> if we don't just make "people" part of the data model API, I still
> think it makes more sense to do the merging process in a central
> component... some sort of "PeopleManager" ... rather than in
> a client library. 

Empathy itself is an IM client. It's basically gaim (pidgin) based
around Telepathy instead of its own protocol plugins.

> (Was that the idea of Galago? I'm not sure what has replaced it these
> days. Somebody really needs to do a glossary of the Telepathy
> ecosystem.)

Galago (if I remember correctly) meant to merge evolution contacts with
gaim contacts. Nokia uses a modified version based on Telepathy instead
of gaim. But there were some design issues with it (eg, it aliases data,
instead of just holding references) and it's basically unmaintained
(except for Nokia's work).

(If I'm wrong on any of those points, someone please correct me).

-Travis