Re: SyncML (was: Phone sync (over Bluetooth)

[Bastien Nocera <hadess hadess net>]

Hey John,

On Thu, 2007-07-05 at 08:06 +0000, John Stowers wrote:
> 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.

Hmm. I should have mentioned that the gnome-phone-manager code uses
gnokii as the backend, and works with most Nokia phones, and AT phones.

SyncML is a very ugly procotol (as Edd Dumbhill, the old
gnome-bluetooth/gnome-phone-manager maintainer can testify).

So we wouldn't be using SyncML in gnome-phone-manager.

> 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) 

SyncML-over-Obex can be implemented seperately, and doesn't have to be
implemented in gnome-phone-manager.

The point is that gnome-phone-manager "polls" (not exactly polling,
there's some notification support as well) the phone for battery, SMS,
and calls. We can add an interface to allow it to issue other commands
(just like it does for sending SMS' right now) for reading or writing
the addressbook.

> 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?

No SyncML, but I'm ready to work on the phone manager bits if you'll
implement the Conduit bits.

> 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. 

I don't really understand the code that much. Would you have an example
of API for me to implement?

-- 
Bastien Nocera <hadess hadess net>