Some more thoughts, now that i've slept. So currently the case study is for Tomboy syncing data to an OGO web notes application with "first class" support for tomboy (i.e. not data loss due to formatting getting stripped, and also making use of metadata from Tomboy such as tags).
In this limited case study I have no problems with using Tomboys own sync. Given Conduit's still somewhat an external entity it wouldn't make sense for this case study. However, what next? Safe to say the "Online Gnome" experience won't stop at notes. I would expect that Contacts or Events would be the next logical kinds of data that would be synced to the OGO platform, or maybe Bookmarks. I think it would be a little mad to implement a sync engine and conflict resolution in Epiphany, Evolution, Firefox, Thunderbird, Sunbird or whatever the user happened to be using. So while its outside Havoc's initial case study this is surely exactly where Conduit steps in. We provide desktop wide "sync smarts" for all these applications and OGO. Now as I've said bookmarks are on their way. Evolution support for Contacts, Events, Notes and Tasks is there. We will be supporting the OGO APIs. (As an aside, It's worth saying that if the Facebook API wasn't over-protective with contact data then Conduit would already implement the "Joe changed his mobile number on Facebook and I want my address book updating" use case. It would have taken about 10 minutes. And have worked with Evolution, iPod address book, Gmail contacts, and would have worked with new "contact" plugins in the future.) So with that said, the support i'm asking for is for someone working on OGO for things other than tomboy notes to say "yes, that sounds like a reasonable approach.. when we get to these we'll help to evolve Conduit for this instead of rolling our own". Does that sound reasonable? Slight change in topic.... Now this morning I woke up. Maybe its only having 3 hours sleep, but I started to wonder how Conduit's DataProvider model could be extended. I'm not talking just about sync anymore. The DataProvider model currently supports a change signal. This is fired when any change is detected and says "hey, you might want to sync now". Typically this signal comes from something like GnomeVFS telling it which file changed (in the future, it will get a Note "blah" added signal from Tomboy). This signal is a bit pants at the moment, but what if it was actually fired and said "Data ABC was added", "Data DEF was removed" (Giving the UID and event type at the least). Now rather than Conduit blindly initializing a full sync it can just sync that single piece of data! This is quite cool from a dev point of view, and excellent for "always up to date". Eh, its even a win on power saving as we don't have to do all the get_changes crap! Now if an individual "conduit" has been unavailable for a while (NetworkManager says no network, but now its back) then Conduit can issue a get_changes type sync to fetch everything up to date.. Then use the new signal to keep them up to date. Also think of a turbo charged version of our current network sync, as soon as you edit a note it will appear practically instantly on the other Tomboy instance (ok, ok it would have anyway.. but watching your notes just appear on the 2nd machine is exciting!! and it does save the get_changes over network wasting time). Right now some of you are probably thinking, you're just boring me with an implementation detail! But think about it, if we take this API and also expose it over dbus suddenly apps built on Conduit aren't just about sync. I'm going to presume for a minute that we can do "PUSH" from OGO. The Conduit API could be used to set trivial watches, not just on OGO but any dataprovider. I'm trying to think of a simple example... How about notifications when something of interest happens? Conduit might already have a "friends photos" dataprovider that gets the change signals from OGO... Or perhaps Gimmie and BigBoard could benefit. They can use get_all to get the current status of various bits of data they are interested in and listen on the changed signal to have their GUIs kept up to date. Depending on how nice we can get the Conduit UI the code needed in any app to grab and keep data up to date seems quite trivial? I suggest this as a way to not have multiple implementations of the same basic access layer. App's like cheese could directly enumerate available dataproviders to figure out where photos can be pushed. Does providing access to this part of our framework seem useful to anyone besides me? :) Or do I need to catch up on my sleep! > > My problem is just a general worry that more and more apps will go do the > > "roll there own" path when Conduit could help, even in the case of Cheese > > which is looking to add Flickr support. > > You have to be on people's radar so they're aware of what you offer. I have > been following Conduit because I think it's cool and has a lot to offer the > project, but I don't know how many other people have been following it. One > point I'd raise about this is that Conduit is less visible to the community > because it's hosted elsewhere. At the moment we try to post on Planet GNOME from time to time, but we don't want to build up too much hype. I don't want to offend anyone here.. We'd love to get on GNOME SVN+Bugzilla, but getting a mailing list took months. So there were some concerns that I would be left unable to commit for a long time (I think John S already has an SVN account?). John suggested we could kick the request off and continue to use our current SVN server until I can get an account, then merge. So point taken, and moving over to GNOME hosting is certainly something that we are looking into. > This 'wall' stuff is a bit unfair, though I can understand why you raise it. > Your path to inclusion in one of the official suites is to propose it during > the release process. Simple as that. One way of attracting attention and > getting things on the agenda is to propose stuff for inclusion even before > it's likely to be accepted. Then the answer is likely to be "this is rad but > not ready yet" and then a project might become part of the defacto assumed > future. :-) > > You're suggesting that being 'outside the wall' is like a state defined for > Conduit that is outside your control. The truth is that you need to start > climbing... or you can just walk through the gate. :-) Looking back I did place Conduit as something of a victim. That was the wrong thing to do, my defense is it was 2AM! We are certainly trying our best to climb, and I hope things like our "Evolution and Tomboy syncing over the network to another Evo+Tomboy" demo will get some people excited of the potential. More importantly, I hope Conduit is on a desktop near you soon :-) *Pokes John about proposal process* > I wholeheartedly encourage you to put Conduit on GNOME's agenda. It's full > of awesome. IDK, To hear *the* Jeff Waugh say that makes me feel all warm and fuzzy inside.. Well I need to get some work done before I fall asleep... John C _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
