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
>> However, actually detecting and merging a duplicate belongs
>> 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!).
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
* 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 184.108.40.206 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
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.