Re: online desktop APIs

[Havoc Pennington <hp redhat com>]

Colin Walters wrote:
> 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.

I think that's fine, the most important place to do the dbus API thing 
is when there's a benefit to sharing across the apps. For example there 
is good reason to have single lists of "people" and "documents"

On the flickr front, I doubt anyone cares if the app uses flickr 
directly or not, but they may care if the desktop is already displaying 
their flickr ID in the sidebar and on mugshot.org, but then the applet 
or app asks for it again. So at minimum if we add the API to get 
someone's account names on their services, that would be a good thing to 
use.

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

Strongly agree.

The really simple thing that would be helpful is if the standard GNOME 
http library (or the ones people are using, like neon or curl) was set 
up, by default, to use the same cookies as the browser. The Windows http 
library automatically uses the IE cookies and this is very helpful.

We should definitely have gnome-vfs/gvfs do this, in any case.

If the browsers could factor out their bookmark system so it was easily 
pluggable with del.icio.us or another service, that would be cool too ;-)

Havoc