Re: online desktop APIs

[Colin Walters <walters redhat com>]

I think that the D-BUS daemon approach can make sense, but I'm not sure
it is going to be necessary for all kinds of things that might fall 
under the "online desktop" umbrella. 
For example if I wanted to write a little Flickr panel applet, I would 
probably just pick up a random Python library
(e.g. http://beej.us/flickr/flickrapi/) than trying to create a daemon 
(with all the packaging/startup/API-design it entails)
and writing my app on top of that.

One major question it comes down to is - how many consumers of the data 
do you expect?  If it's just 1, possibly
two, then a daemon approach probably isn't necessary.  If there are 3 or 
more, then it is probably a good idea. 
Another test critera is whether notifications are important, and whether 
or not the service provides a mechanism
for notification.  Mugshot being true for both, Flickr false for both, 
something like Google docs would be true for
the first but not really the second (as I understand it).  The D-BUS 
daemon approach is going to be better if both of these
are true.

Kind of an aside but - in terms of APIs useful for online applications, 
one thing that is sorely needed
in my opinion is a common library for accessing cookies and http 
caching.  We have bits of the former in the Mugshot
client, but it should probably be broken out, and it would be good if it 
supported more browsers too.  For http caching, ideally
we would just reuse the active browser's cache, instead of having it 
per-app and stored in random places.  I'm not sure if e.g. Firefox
exposes a remote interface to its cache though.  Neither of these things 
are very sexy though, admittedly.