On Mo, 2010-11-15 at 13:43 +0000, Patrick Ohly wrote:
> On Do, 2010-11-11 at 14:52 +0000, Patrick Ohly wrote:
> > Hello!
> >
> > I have a question about matching items. Here's my situation:
> > * Client and server both have the same iCalendar 2.0 VEVENT (UID
> > is identical).
> > * SUMMARY is changed on server, one line is added to description.
> > * SUMMARY is changed on client.
> > * Slow sync.
> >
> > I had changed the "calendar" field list so that all fields have
> > compare="never", except for UID and ORIGSTART, which have
> > compare="always". The rationale is that if it is known that both sides
> > support UID, that alone should be used to find matches.
> >
> > What I expect in this case is that:
> > 1. Synthesis engine finds the match.
> > 2. The more recently modified SUMMARY from the client is preserved
> > (DMODIFIED = LAST-MODIFIED is marked as age="yes").
> > 3. The additional line of the description is preserved (DESCRIPTION
> > has merge="lines").
> >
> > What happens instead is that the engine finds the match, but then skips
> > merging the items and updating them on server and client, leaving them
> > unsynchronized. Is that the desired behavior? Do I have to configure the
> > engine differently?
>
> Yes. Lukas told me that there are configuration options, and then I also
> found them in the documentation:
>
> 11.36.6 <updateclientinslowsync>: update client records
[...]
> If this option is set in a remoterule, the SyncML server will try to update
> client records with
> server data if comparison shows that the server has additional data that the
> client does not have
> during non-first time slow sync.
The "non-first" part here is important: a first-time slow-sync is when
client and server have never been synchronized with each other. In that
case, these options are not necessary to get the desired behavior.
However, I was forcing a slow sync between client and server which had
already synced, so I wasn't getting the expected updates. I wasn't
expecting this special treatment of non-first slow syncs, but now I see
how it might make sense: it avoids unnecessary updates when just
re-syncing two peers which already have the same data, where data
differences are more likely due to minor differences in data
representation rather real user changes.
Now that I had that sorted out, I was running into another configuration
issue: <slowsyncstrategy>duplicate</slowsyncstrategy> is set in the
syncserv_sample_config.xml and SyncEvolution copied that. Therefore the
engine ended up trying to duplicate events despite a UID match. This is
not possible in the backend, which will always overwrite the existing
event. So what I need in this case is "newer-wins" with "server-wins" or
"client-wins" as fallback instead of "duplicate" - such a setting does
not exist, does it?
Finally, remember that I had intentionally created differences in the
SUMMARY of my two events. My expectation was that this difference would
be resolved during syncing.
However, this is not happening. Is it because the "merge" parameter for
field "SUMMARY" is unset and thus defaults to "no"? Rereading the
documentation, this seems to imply that the engine doesn't touch this
field at all. This comes straight from the syncserv_sample_config.xml.
Is that really intentional? In the case of merging based on "newer", I
was expecting all fields with the default merge policy to be copied from
the "newer" item. Setting any of the existing merge policies (like
"fillempty") doesn't look quite right.
For example, if the winning item has no CATEGORIES set, should
"fillempty" preserve the categories?
Note that I made another change for my iCalendar 2.0 case: all fields
have compare="never", only UID/RECURRENCE-ID has compare="always". Could
that have an effect on merging once pairs are found? After looking at
the code it seems so. compareWith() returns that the items are identical
enough, despite the change in SUMMARY.
So let me summarize. Is there some way to specify that:
1. only UID/RECURRENCE-ID are used to find matches
2. duplicating matching items can never be done
3. properties like SUMMARY must come either one or the other side;
more specifically, in a case where one side is newer, from that
side
4. properties like DESCRIPTION can use more intelligent merging
("lines")?
--
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
