Hi everyone This is my third attempt at this e-mail - it's hard not to waffle or repeat myself! It's getting late now so my English may have degraded into nonsensical babble :D
The purpose of this e-mail is to consider Conduit as part of the Tomboy case study. How can Conduit help deliver "Tomboy online". What benefits does it bring, what disadvantages. What would be the architecture and so forth. Hopefully I will convince you that sync can be generic and that Conduit doesn't care whether its dealing with a "data store" or something that understands what that data is. That's really a separate issue completely to Conduit and generic sync logic. Conduit is really split in to several parts. Firstly we have a collection of dataproviders. Dataproviders are the application specific parts. No one likes having a common interface, that would be easy and boring, so DP's map everyone's home grown API's onto an established baseline. For easy reference, the basic API is: get_all() - return a list of UID's (think ls) get(uid) - returns an object put(uid, obj) - returns a uid delete(uid) And object needs a unique id, an hash (so we can tell if its changed), and data to sync! An hash could just be the last modified time or a serial/revision number. With this the next layer of Conduit can actually sync two DP's together. It doesn't matter what they are, local or remote or a device. The important thing is the format of the data. Now in some cases this means conversion, but Tomboy Online can be built to use Tomboy's format natively. So no format conversion. We also provide some infrastructure for notifications. These allow a DP to say "hey i've got new data to sync!!". DP's can be made available dynamically... This means they appear in response to system events - be it avahi or HAL. This is especially useful in sync GUIs but its available to any app that cares over Dbus. The Conduit GUI is really a "pretty thing" on top of our core code. If we have a wizard to turn on "Tomboy Online" out of the box the user might not even see the Conduit GUI. Hopefully it should already be clear how this fits in with the online tomboy notes: * We commit to enabling the automatic background sync feature, which in the scheme of things is quite trivial. It's already partly implemented. When thats done, the experience then becomes pretty darn seamless for the user. * Tomboy remains pretty much unchanged (work to have change notifications from tomboy are underway anyway - its something Sandy already offered to implement for us). * Conduit gains a dataprovider plugin that can sync notes to online.gnome.org through whatever protocol you suggest. This protocol will have to update the Tomboy online data model from the server end. (This may relate to (1) and (3) in your original e-mail. I must be missing part of the ogo stack because I don't see a problem there. Somehow we need to pass the data to the server - WebDAV, REST, direct database access. It doesn't matter. But that doesn't mean that the server can't understand the data. I can send it a file through WebDAV and it can be processed and stored in a DB, or whatever suits the application. So i'm sure i must be missing your point when it comes to (1) and (3)?) * Hopefully the server API will use something like http://brbx.com/orbited so that updates at the server end can appear locally immediately. I could be wrong but I don't think (2a) is possible with a PUSH feature like im suggesting here. (Though it is possible if using Conduit). * For free, Evolution Memos can be put on Tomboy online. The same codepaths allow devices to sync and peer 2 peer without needing separate interfaces. I think an important thing here is that some people won't want online.gnome.org. Personally, i might be tempted to use Conduit to sync them to an SSH account or a password protected area of a server I control. By integrating Conduit people have that choice, and at the same time we don't waste time on multiple sync implementations. I'm not saying Conduit is perfect, but i'm sure people we've worked with will back me up when I say that we will work to resolve any issues we encounter. In closing, I wanted to point out that Tomboy didn't implement its own sync because of Tomboy specific logic. It implemented it's own sync because it was highly desired by GNOME users and yet neither Conduit or OpenSync are first class citizens in the GNOME desktop.. This made reuse something of a no-no (this is documented online, and Sandy or Boyd.. correct me if I'm wrong there...) Apologies if i've glossed over anything there. I'm trying to keep it concise, and i've failed. I've already spent well over 3 hours on my response :-) If something doesn't add up i've probably over-simplified some aspect or completely forgotten about it. Tell me off and i'll try again :-) John C ( Sorry if i put you to sleep ;) ) _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
