Re: Hints for opensync a gui - multisync-gui

["John Stowers" <john stowers lists gmail com>]

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/