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



I really like the last ascii diagram here.  I think it reflects more of
the direction we were discussing at GUADEC.  Assuming we take that
direction (which I would agree with) I'd like to see a dbus interface
into the [[online-desktop-engine]] which would become the (generic data
model API).

-Calvin

On Wed, 2007-07-25 at 15:42 -0400, Owen Taylor wrote: 
> On Tue, 2007-07-24 at 22:27 -0700, Travis Reitter wrote:
> > At GUADEC, a number of the people-centric software people (from Soylent,
> > Banter, Empathy, Telepathy, Mugshot/Online Desktop) got together to
> > discuss some issues around integrating our work.
> > 
> > Here are some ideas for the short-term implementation, to get us rolling
> > on integration. Many of these based on other peoples' ideas, but here's
> > how I think it can all fit together. This isn't exhaustive, and mainly
> > focuses on issues related to people-centric apps.
> 
> I'm going to respond a little out of order here. First I want to point
> out the things that I really agree with:
> 
> > [...]. I think, and I believe we
> > largely agreed in the discussion, that we care mainly about the use
> > cases with intermittent network connectivity as opposed to use cases of
> > rare network connectivity. If you rarely have an Internet connection,
> > the Online Desktop won't be very interesting to you.
> 
> Exactly ... we shouldn't think about synchronizing your machine's
> addressbook with some other addressbook, we should think of it more like
> IMAP where you may have some ability to do things offline, but it's
> clear that you are editing the online copy.
> 
> > As much as possible, I would like to avoid manual metadata entry. The
> > social networking model works very well for this. That way, you fill out
> > your own details once, mutually connect with people, and that's it. Each
> > time your friends update their profiles, your address book is updated
> > automatically. This substantially beats the old desktop equivalent,
> > where you have to manually enter and synchronize your contacts' full
> > profiles on each of your devices.
> 
> This too - I don't think people interact with addressbook interfaces
> much at all these days ... if you send email to somebody, your email
> program remembers it. If someone you meet gives you their facebook
> info, do you go and add it to an addressbook? No, you make a note
> of it, and next time you are online, you go to facebook and add them
> as a friend. Centering an interface around data entry for other people
> doesn't make much sense.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 						- Owen
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list




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