Alex, just wanted to throw in my thoughts as an outsider.
I like to keep up with the developments in the free and open source software world. I track a fair few blogs and planets and wade through around 80 posts a day in my aggregator (maybe more). In that time i’ve read a lot about gimmie. I was impressed. I tried it, and was even more impressed! Despite hearing lots about Gimmie, I haven’t heard anything about BigBoard. And it would seem it’s developers are just as much a part of “Planet Gnome” as yourself? Anyway, I just wanted to say that I can’t wait to see what happens in Gimmie next 
The discussions about accessing web services made me consolidate a few points i’ve have for a while and i’d like to share with you (and the community in general). On the desktop we have lots of data we want to share, to sync, to, well, use!
- Banshee has to learn how to talk to each type of MP3 player to sync it’s library
- So does Rhythmbox, but in a different language.
- Beagle and Tracker have to learn how each application stores its data so you can search it
- Gimmie has to learn how to talk to generic web app X, Y and Z and how to get any interesting and relevant desktop data
- Conduit is a sync tool and so has to do all this and some more!
- Tomboy wants to be able to sync too
I think it’s great how useful these applications are, but I think a lot more could be done to share data. It’s not really about whacking together a library so two apps can talk to an iPod. That’s bad because each app using it has a layer of glue to link it in to their plugin system. I think instead we as a community need to think in terms of objects that people are using. Have a common way to share a photo between different applications and devices and webservices. Sort of like a higher level VFS.
My utopian vision then.
- It would be nice if Tomboy officially used Conduit to do it’s syncing. Right now that means that you would be able to sync Tomboy to any folder that VFS can see, to an iPod and (i believe) BackPackit. And google notebook wouldn’t be difficult. As more dataproviders are developed for Conduit then this list will increase greatly. The todo list includes my network code which would allow Tomboy to Tomboy over the network. The same code will enable F-Spot to F-Spot etc etc. Why reimplement from scratch when we can do this now?
- More work would be done on the Conduit Web Services stuff and Gimmie would be able to use our DataProvider framework to query these different kinds of sites. And because the DP’s are responding with generic Photo or Contact objects its trivial for Gimmie to handle other DP’s too. The same code could show a Photo from Flickr or a photo from a folder, just need to pick the DP! Because Conduit is in python too then Gimmie could probably directly reference Conduit code rather than going through the DBus API even. If Gimmie can consume one dataprovider, it can pretty much consume them all!
- Banshee and Rhythmbox would have Conduit plugins so that they can use the Conduit DataProvider framework to work with music devices. This is instead of them writing glue around each generic-music-player-support.so. Conduit would provide one set of glue. Both Banshee and Rhythmbox would then support every DAP Conduit ever does (them ALL >: ).. I dream..)
- Tracker and Beagle would be able to use our DataProviders to build their indexes. Why have two different sets of glue code for reading the same data out of evolution and f-spot? You can talk about speed I suppose, but I want a desktop that’s integrated. When I want to scrape out every last MhZ out of a box i’ll give Xubuntu a whirl!
I don’t know how well i’m making my point here. But I don’t see why all of these projects can’t work together more. If they could all pass around these common desktop objects then surely everyone would benefit?