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

[Owen Taylor <otaylor redhat com>]

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.

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?

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

(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. 

(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.)

                                            - Owen