>
> 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.
OK no problem.
I saw the gnokii dependency but myself have a Motorola phone so thought another plan would be in place.
> 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.
OK. I will look at binding the libsyncml library in python for my own use.
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.
No problem. Aim for address book and sms support? That way people could do sms <--> notes or evolution memo sync for example.
> 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?
OK Sure. Reading your post again I see that you want to use conduit two ways. As a conduit client, and as a dataprovider. The former basically allows you to provide a "Sync phone address book with evolution" button in the g-p-m applet, while the latter provides a means to transfer data from the phone, via g-p-m to Conduit. The latter is required for the former [1].
Controlling Conduit Remotely (using conduit as a client):
------------------------------------------------------------------
This is the example provided in the photo upload tool. There is basically three steps. Apologies that the code is in python
1) Connect to conduit over DBus
bus = dbus.SessionBus()
conduit_object = bus.get_object('org.gnome.Conduit', '/')
self.conduitApp = dbus.Interface(conduit_object, 'org.gnome.Conduit')
2) Setup the sync partnership you wish to sync. E.g. addressbook to evolution contacts
self.source = self.conduitApp.GetDataSource("GPMAddressBook")
self.sink = self.conduitApp.GetDataSink("EvoContactTwoWay")
self.conduit = self.conduitApp.BuildConduit(self.source, self.sink)3) Connect to signals and set any synchronization options
self.conduitApp.connect_to_signal("SyncCompleted", self.sync_complete_cb
)
self.conduitApp.connect_to_signal("SyncProgress", self.sync_progress_cb)
self.conduitApp.SetDataProviderConfiguration(self.sink, xml_config_options)4) Sync
self.conduitApp.Sync(self.conduit
)
So thats about what you need to do to control conduit remotely. You will get a callback when sync completes, and also progress updates so you can draw a progress bar (for example). The DBus interface is not the most OO (its on the TODO list to fix) but it can basically do what you need as it. Obviously instead of EvoContactTwoWay you could sync to a Folder of vCal files, an iPod or whatever. The only hard coded intelligence needed at g-p-m end is the names of the dataproviders (
e.g. EvoContactTwoWay) and some knowledge of the configuration parameters required for each dataprovider (e.g FolderTwoWay must be configured with a folder path)
Implementing a Dataprovider for Conduit
------------------------------------------------
The title is a bit misleading as I will implement the GPMAddressBook dataprovider for you but this is a basic outline of the requirements of a DBus interface which I will use. John C may be able to clarify this somewhat as he has been discussing the addition of such an interface to f-spot.
The conduit sync process is 4 step
1) refresh()
2) get_all()
3) get()/put()/delete()
4) finish()
One requirement is that GPM provide some sort of UID that represents a phone contact such that this UID can be used to get() and delete() a contact from the phones address book.
With that in mind the basic DBus i/f that I would code to would look something like this
GPMApp.GetAllContacts()
--> Returns a list of UIDs
GPM.GetContact(uid)
--> Returns the contact data for the contact with uid
GPM.DeleteContact(uid)
--> Deletes contact with uid. Returns True/False
GPM.StoreContact(contact)
--> Store a contact to the phone. Return the uid of the contact that was stored
GPM.ReplaceContact
(uid, contact) (optional)
--> Like above but replace the contact at uid
GPM.GetContactMtime(uid) (optional, if supported)
--> Return the modification time of the contact
Notes:
ReplaceContact is optional because I could just call DeleteContact() and then StoreContact() client side.
GetContactMtime() is also optional because if the concept of modification time is not supported then we can fall back to object hashing to detect if a contact was modified or not.
Notes About the Data Format:
You can use whatever form you like to represent the address book contact. Providing that I (the author of GPMAddressBook dataprovider) know the format I can convert it into our standard contact format (vCal) for synchronization with other dataproviders. It is likely that this will be easier and faster for me to do in python that you to do in C.
[1] This alludes to our future plans with respect to data formats. The implication of this, and the paragraph above is "if you use your own data format then a conduit dataprovider needs to be written to convert that that format to our types. If you instead choose to use our data formats (
e.g. some $FUTURE xml standard contact format) then the wrapper around your applications DBus interface can be wafer thin and avoid all need for data conversions. This plan is very much hypothetical at this stage but I am noting it for future reference.
Everything I described is already possible with conduit and the GPMAddressBook dataprovider will only need to be a handful of lines for basic support.
Let me know if this clears things up
John
--
Bastien Nocera <
hadess hadess net>
