Hey Everyone, The goals of Conduit have changed since somewhat since I started working on the project about 8 months ago and its probably time I clarified a few things.
I started Conduit to address synchronizing data that is not really of the PIM (calendar, contacts, etc) nature. For example I wanted some way to automatically sync my favorite photos with Flickr, sync my Tomboy notes between computers, sync two folders over gnomevfs shares (ala iFolder), etc. Today (minus day-to-day regressions, Conduit svn can do these things more or less today). The secondary motivation was to remove the need for each GNOME application to implement an export interface for the newest web 2.0 service that pops up, "export photos to google photos/flickr/facebook/23/etc, etc/". Conduit has been designed with complete interation and control via DBus as one of the primary goals. (FWIW this is one of the reasons I chose to write Conduit in python - most websites get python bindings first!) Anyway, since then I have deviated a bit from that goal. My major goal after the next (0.3.0) conduit release will be Evolution python bindings of sufficient quality so that I can work on addressing some PIM sync use-cases (gmail, iPod, etc). The other will be bugfixing the Tomboy support. I had initially wanted to start to integrate with OpenSync at this stage, probably using the opencync python bindings [1]. Since then I have done a lot more looking over the problems remaining, for a desktop wide sync service, and changed tact a bit. Architecture wise, the conduit framework, and the OpenSync framework are (in my highly biased perspective) about the same. The killer app that OpenSync has is mobile phone support. If I was to pick a point for the two to converge it would be via a desktop syncml daemon. My Plans for a sycml desktop daemon: Currently OpenSync does mobile phone support (for the most part) using libsyncml [2]. In the libsyncml distribution there is also a standalone http server (for sync using syncml over ip) and a syncml-obex-server (for sync over bluetooth). Given more time I would like to modify the libsyncml http-server to be exclusively controllable over dbus. I would then talk to this from conduit over DBus. Finally to minimise duplicating all the effort of OpenSync I would modify the opensync syncml plugin to talk to the http/obex server over DBus. I think this approach is a natural way of improving syncml support on the desktop. Finally I am actively looking to integrate Conduit more as a desktop service and making sync simple. Perhaps the OpenSync (backend) guys are more interested in providing a good PIM sync experience, desktop neutral, and fair enough, that is their perogative. I will eventually get to PIM sync but am interested in addressing more diverse cases first, both as a test of the scalability of the framework, and because I use gmail for everythin anyway! I would however like to start a discussion with the gnome-bluetooth guys, and any other interested parties on the feasability of a gnome-mobilephone-daemon type application which is an aggregation of gnome-obex-server and also contains the libsyncml server parts I described above. Thoughts? John [1] http://svn.o-hand.com/repos/misc/trunk/sync [2] http://libsyncml.opensync.org/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
