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