On Tue, 2011-08-16 at 15:24 +0200, Lukas Zeller wrote:
> On Aug 16, 2011, at 12:54 , Patrick Ohly wrote:
> >> All but the first bullet point are not implemented so far.
> > 
> > I had to resolve the double negation before this sentence made sense to
> > me ;-) So the "read back" bullet item is implemented, the rest isn't.
> 
> Correct! That was a case of too many edits ;-)
> 
> With the patch below the entire list (plus also handling not just
> add<->add conflicts) is implemented (but not yet tested).

I would have to write a test case and try it out before I can comment on
the patch.

> >> However, actually detecting and merging a duplicate belongs into the
> >> backend, as the search usually must extend beyond what the engine sees
> >> as "current sync set" (imagine a date-range filtered sync, and an
> >> invitation added on both sides which is to far in the future to be in
> >> the date range window. The candidate for a merge could not be found in
> >> the sync set!).
> > 
> > Agreed.
> 
> So what's missing right now is a simple way to actually do the merge
> in the backend, without re-implementing half of libsynthesis. The
> (hopefully not so) longterm solution would be libvxxx. As a short term
> workaround, which is not exactly super elegant but not dangerous
> either, we could do the following:
> 
>       * we define another special return code for AddItem, say 419.
>           The backend can return it when it detects that the added data SHOULD
>           be merged with what the backend already has, but can't do that
>           itself.
> 
>       * the engine would do the same things as (details see commit msg
>           in the patch below) for 207 but additionally it would:
>         * merge the incoming data with the data fetched from the backend
>             with the localID returned from AddItem()
>         * call UpdateItem() with the merge result in the backend
>             
> Let me know what you think...

That sounds like it would solve the problem.

I'm currently debating with myself whether I'll release 1.2 with the
known issue around add<->add conflicts in CalDAV sync. It is very likely
happen in an enterprise scenario where the calendar adds all meetings
automatically. But there's also an easy workaround: sync the calendar
before processing meeting invitations in email locally.

I'll release 1.1.99.6 with that known problem because it has a more
pressing issue causing "event not found" errors which was fixed in the
source, but not released yet.

Add<->existing merging can't happen because both sides perform UID
checking.

-- 
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
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to