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