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
