Re: SyncML, Google Calendar, and Soup.

[John Carr <john carr unrouted co uk>]

Quick update,

SyncML support has continued to mature. I'm reasonably happy with how
trunk libsyncml and this branch are performing against ScheduleWorld.
Going to check it still works with my phone shortly.

I think initial syncml support will be ready to merge soon.

Spent some time on my AutoSoup replacement. So far i've written 6
tests to test the interface of a DataProvider, 5 to test basic
DataType behavior and 11 simple sync scenario tests (things like 'what
happens if i add stuff, sync, modify stuff, sync). At the moment a
'full run' runs 202 combinations of these tests (in less than 30
seconds) (this is covering the folder, ipod and n800 backends, with
tomboy and evolution both pending). There are currently 10 failures,
which represent 2 bugs. One of which is some of the iPod backends dont
support put overwrites, they just add new data :( :(

It also gained code coverage and profiling support. Should also gain
some crack to run tests with their own session dus and grab
dbus-monitor logs of the test run (its about half way there). I'm also
going to add options to drop you into pdb on exceptions and to run a
test in the debugger.

I'm also trying not to stray too far from unittest style tests, so it
should be possible to have an optional dependency on python-testtools
in the future and allow multiple tests to run at the same time.

I'd like some feedback on this sooner rather than later (before i
start testing syncml with it).

John

On Mon, Apr 27, 2009 at 2:31 PM, John Carr <john carr unrouted co uk> wrote:
> 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
>