SyncML (was: Phone sync (over Bluetooth)

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

Bastien,

Great timing as I was just drafting this post to the conduit mailing list[1] (which I CC'd this to). In light all the good PR conduit has been getting [2] I thought I would share my thoughts wrt syncml support in conduit.
I had initially planned to implement this via some sort of sycml desktop daemon, however your mail suggests that g-p-m is growing a DBus dependency so I would like to discuss placing the support in there directly.

Currently OpenSync does mobile phone support (for the most part) using libsyncml [3]. In the libsyncml distribution there is also a
standalone http server [4] (for sync using syncml over ip and debugging) and a syncml-obex-client [5] (for sync over bluetooth and debugging). Currently these tools allow basic things like getting all the contacts off a phone, etc.

Ideally I would like to modify the libsyncml http-server to lie within g-p-m and be exclusively controllable over dbus. I would then talk to this from
conduit over DBus.

I think this approach is a natural way of improving syncml support on the desktop while converging with OpenSync at the layer that really matters. Initially I was going to wrap libsyncml in python, but thought that having it available via g-p-m would be more useful desktop wide, and would give a central place to apply policy such as "use conduit to sync when a phone is connected" and so on. Having DBus as the data transport medium would also allow other interesting things in future (such as automator support, and command line users to get access to the phones information)

I am prepared to implement support for this in g-p-m, but may need a little help with where these things should live in the g-p-m tree (or the gnome-bluetooth tree?). What are your thoughts?

Regarding your other questions - how to get conduit to sync something remotely. I have a Flickr photo uploader in the Conduit tree that uses Conduits DBus interface to sync photos with Flickr [6]. It demonstrates the half a dozen DBus calls necessary to sync something.

John

[1 http://mail.gnome.org/mailman/listinfo/conduit-list]
[2] 
http://www.venturecake.com/10-ideas-to-improve-gnome/
 
http://itmanagement.earthweb.com/osrc/article.php/12068_3678071_5
[3] http://libsyncml.opensync.org/
[4] http://libsyncml.opensync.org/browser/trunk/tools/syncml-http-server.c
[5] 
http://libsyncml.opensync.org/browser/trunk/tools/syncml-obex-client.c
[6] 
http://www.conduit-project.org/browser/trunk/tools/yaput/Yaput

On 7/5/07, Bastien Nocera < hadess hadess net> wrote:

Heya,

I'm currently working on updating gnome-phone-manager to do useful
things[1], and realised that I could integrate it in Conduit to provide
addressbook (eventually notes, sms, alarms, etc.) sync.

My Python sucks, and I've already got a lot on my plate with other
Bluetooth stuff, so my idea is:
- create/tear down a D-Bus service when gnome-phone-manager connects
to/disconnects from a phone (using Bluetooth, USB, or serial)
- offer a few methods over D-Bus: get addressbook entries, save
addressbook entries
- Conduit has a sync and source allowing to read/write using g-p-m

If you guys have a good idea on the API needed, I'd be happy to
implement it (although it would have to wait a bit for my TODO list to
shrink).

What do you reckon?

BTW, any of you coming to GUADEC?

[1]: used to do only basic new SMS reading/writing, I'm adding battery
information, and calls notification
--
Bastien Nocera < hadess hadess net>