On Tue, 2012-02-07 at 16:05 +0100, Patrick Ohly wrote:
On Mon, 2012-02-06 at 21:29 +0100, Patrick Ohly wrote:
I'm currently experimenting with a different approach for handling the
409 in the binfile client: when an Add fails with 409, catch it as it is
done at the moment, but then tell the server that it was mapped to a
dummy LUID. Mark that LUID as deleted in the change log. Then in the
next session, delete the redundant item on the server.
I'm combining that with running multiple SyncML sessions in the same
context.
Will post code soon...
The result is in the internal-sync branch in the meego.gitorious.org
repo of libsynthesis. It's called internal-sync because I am working
on an extension of the SyncML protocol that is only understand when
SyncEvolution talks to SyncEvolution (either in the SyncEvolution local
sync mode - see the
http://syncevolution.org/blogs/pohly/2012/fosdem-2012 talk for a diagram
illustrating that) or in SyncEvolution client to SyncEvolution server
mode.
Instead of repeating myself, let me quote the commit messages of the
relevant commits on that branch below. There are a few more commits in
that branch. Lukas, what do you think?
This is not done yet, but if possible I'd like to get feedback before
going down an entirely wrong path. Some tests for this new code are in
SyncEvolution (not pushed yet) and pass as expected. I'll keep working
on this, in particular the temporary problem part and add more data
in second cycle cases.
I've also pushed the internal-sync branch for SyncEvolution. It has
tests for the 409 in client of dumb SyncML server problem
(testAddBothSides when configured to use SyncEvolution server with file
backend), restarting a two-way sync with
SyncContext::requestAnotherSync() (testTwoWayRestart) and the extended
SyncSource semantic. All of that works fine.
It took a bit longer than expected because writing these tests required
quite a bit of code refactoring.
Speaking of the extended semantic that beginSync() may be called
multiple times: right now this is mandatory. My hope is that backend
implementers will adapt to that change before releasing 1.3, or that no
such changes are necessary. EDS and file backends worked fine without
changes. I prefer that approach because it avoids special cases.
Mikel, most relevant for you is the new
SyncSource/SyncContext::requestAnotherSync() API call. You might be able
to implement the two-phase transfer of contacts like this:
1. In first beginSync() call:
* only retrieve contacts without PHOTO data
* ask for another cycle with requestAnotherSync()
2. In the second beginSync():
* also retrieve PHOTO data
* mark all contacts with new or updated PHOTO data as
updated
I also implemented the backend is read-only part. The Synthesis engine
already had that, it was just a matter of making that available in
SyncEvolution.
You can rebase the PBAP branch onto internal-sync. I'll refrain from
rebasing internal-sync from now on.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
