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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
