SyncML, Google Calendar, and Soup.

[John Carr <john carr unrouted co uk>]

Hi Guys,

Just an update on my SyncML efforts (and other work). You can check
out the progress on github:

http://github.com/Jc2k/conduit/tree/syncml

Currently the work has concentrated on acting as a HTTP client (for
synchronising to Schedule World) and Bluetooth OBEX (for synchronising
to mobile phones). libsyncml doesn't have any python bindings upstream
so i bound the new "easy" data sync api found in recent versions (i'm
testing with libsyncml 0.5.2). It's a ctypes binding thats mostly
generated automatically using some Vala crack i wrote - so want to
avoid editing it directly.

Most of the work is in the SyncmlDataProvider class. This handles the
delicate dance between Conduit threading and libsyncml threading. This
still needs work to handle error cases better (read: at all). It
handles both the Server and Client SyncML modes (if you are unfamiliar
with SyncML: A server can initiate a connection to a client just as a
client can initiate a connection). A server can also request slow or
fast syncs, so if a remote is only sending changes we implement
get_changes(), otherwise we raise NotImplementedError and fallback to
get_all(). Note to self: Need to sit down with a pen and paper and
think what it means if we only send changes during a slow sync.

There are mixins to specialise this provider to deal in Events and
Contacts and mixins to configure for typical HTTP client access and
typical Bluetooth OBEX. Theres also a simple BluetoothFactory that
creates DataProviders for paired bluetooth devices (and removes them
if the device is unpaired).

Not ready to merge just yet, but getting there. Concentrating on
ScheduleWorld right now which works one way but is having trouble in
two way.

Also on my github you will find:

A branch to turn Google Calendar back on. Not much to say on this. I
havent had time to stress test Google Calendar yet but i'm hoping to
find time. A lot of people keep asking where this went - i'd like to
merge and turn it back on if possible.

A branch for a new approach to my old (presumed bitrotted) AutoSoup
tests. You create a class for each dataprovider that knows how to set
up a test instance and optionally how to validate test outcomes (there
is a default implementation this is the case for the syncml provider).
A stock interface test and sync test is then generated for each
dataprovider. In the case of the sync test, it generates a test for
each combination of dataprovider (thats makes sense). The aim here is
to be able to give each dataprovider a brutal testing whilst needing
hardly any custom code. Nowhere near ready to merge, but wouldnt mind
input (especially objections) before i waste too much time.

John