Re: online desktop APIs

[Havoc Pennington <hp redhat com>]

Rob Taylor wrote:
> Agreed, to this end, I've got a dbus-doc project going on fd.o[1], based
> off Jon McCann's stuff for ConsoleKit. Its still very very young, so
> comments and input much appreciated.

Cool!

> I also have concerns that this seems very mudflap-oriented. 

http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging ?

Assuming you mean Mugshot? The point of the new API I posted is to 
"de-mugshot" things a bit so in principle another server could be 
substituted. (Though after talking to Owen we're already considering 
changing this API a lot, so the API will be more generic - essentially 
the Mugshot client would become more of a pass-through proxy and cache 
for APIs the server provides, instead of a provider of custom-written 
dbus APIs; the idea is that you could patch the server and patch an app, 
without requiring a patch to the intermediate Mugshot client thingy)

Though we want to keep things cleanly engineered so someone could 
replace Mugshot, at the same time using Mugshot is the only practical 
way to get things going IMO, for a variety of reasons. Some of the major 
ones:
 - we need an open source server under the control of the development
   community, because web services provided by existing sites and
   companies aren't sufficient. We want to use what exists - say
   Flickr for photos - but then be able to fill in gaps. So for example,
   we had to write our own browser for open source apps at
   http://mugshot.org/applications
 - it's an admin'd, hosted, clustered application server instance that
   has both jsp and xmpp channels, and any server-side function can
   be rapidly added to it; doing a new server-side function from scratch
   has *a lot* of overhead vs. adding to Mugshot (and also has end user
   overhead, e.g. signing up for the new server)
 - because it has web-only and Windows versions, social features need
   not assume that all my friends use Linux
 - the "data model" of the Mugshot "meta social network" or whatever you
   want to call it is what we think we want user experience wise, vs.
   say a "my contact database" data model. For example, people choose
   their own photo and nick, and maintain their own addresses, you don't
   have to import or edit these things.
 - we already have major functionality slices such as tracking your
   friends' photos and feeds, tracking who's listening to what,
   partially-complete file sharing, and social application
   browsing/installing/launching

Theoretically, a federated or peer-to-peer architecture would be better 
than relying on a server; but IMHO for a lot of things federation/P2P 
are technologically intractable or at least hard research problems. So 
my assumption is that we can only use P2P opportunistically when it is 
workable, but need a central server otherwise.

It is just 1000% simpler if we start by saying "here is the server the 
project is based on. We'll assume it exists and rely on it."

It's been a huge handicap for the last several years that when coding an 
open source feature, there was no way to deploy and rely on server-side 
infrastructure, so we want to fix that.

> It'd be nice
> to see some synergy going with eds-dbus. Personally I'd like to see an
> fd.o standard for accessing contact information. Also presence-wise we
> already have Galago and Telepathy, it'd be good to get a discussion
> going how all this fits together.

We exchanged some initial private mail with Robert McQueen on this. It 
is not clear to me what the answer is, it does seem to relate somehow, 
but I'm not really sure yet.

The social network model of contacts is not quite the same as e-d-s, 
since people edit their own entries, rather than everyone editing their 
own copy of everyone else's. The Mugshot database schema does allow an 
"overlay" of per-person contacts that aren't in the social network (that 
don't have an account) but it does not trivially map to the way e-d-s 
works, though it may be mappable.

Another element of the social network is groups of course. The Mugshot 
social network has "entities" in it that are people, groups, "bare 
IM/email addresses," and "RSS feeds"

Also involved here is that I'd like to "merge" buddy lists and also 
people on the local LAN, but not as a one-time import, rather I'm 
thinking these would dynamically merge when you are signed on to the IM 
service. When signed on we'd also want to get presence information.

Telepathy can provide this, but only if people are using a Telepathy 
client. Right now people are using mostly Pidgin/Gaim and X-Chat 
instead, I would guess. So using Telepathy doesn't really get us 
anywhere in the short term on that front. In other words there is a 
chicken-and-egg problem.

I'm sure this will work itself out more as we go, I think the right 
starting point is more top-down and starting with the essentials. I 
don't really expect that we can build the right ultimate API on the 
first try.

For me, the right top-down thinking is that our user model is social 
network / buddy list, rather than Outlook-style contacts; and of course 
the fundamental premise of the project is that we want this info stored 
online primarily, rather than locally primarily. So we want as a first 
cut to be sure we have those properties, and then massage stuff into 
sharing as much code as we can with projects that don't share the 
assumptions. Probably we can share quite a bit.

It will get easier to share code over time as we become successful, 
since the more experimental our "online desktop" is the less willing to 
take patches for it people will be ;-)

Havoc