On Do, 2011-06-23 at 12:41 +0200, Lukas Zeller wrote: > On Jun 22, 2011, at 11:05 , Patrick Ohly wrote: > > > On Mi, 2011-06-22 at 09:57 +0200, Lukas Zeller wrote: > >> Hi Patrick, > >> I'm not sure how the "unprocessed" properties should ever be used with > >> this change. > > > > I agree, they are never exchanged with a peer. > > > > But they are used locally, which is my main use case right now: > > 1. Parse vCard from EDS, populating XPROPS from X- extensions not > > mapped to anything else. > > 2. Synchronize with Google (using that as example because its vCard > > is so woefully incomplete - doesn't even include BDAY, even > > though the Google web interface does support it): no extensions > > sent. > > 3. Modify on Google. > > 4. Receive update in next sync: read vCard from EDS, parse it as in > > step 1, preserve XPROPS (because they are marked "n/a") when > > applying update, write back with X- extensions. > > > > That gives me the desirable "no data lost round-trip sync". > > Ok I see. However, I don't think the change in > 92d2f367e72eccedb2cd1e103ec7770b6a426ef2 is a good idea. It's > basically reverting 3529d3cb09 (engine: implemented "unprocessed" > wildcard properties to allow handling unknown extensions (like X-xxxx > properies)), where I added the clause to make fields mapped to > "unprocessed" properties always available, because otherwise they > cannot be used at all in sync.
The key question is: is the assumption that a peer supports extensions or is the assumption that it doesn't? In the former case, wildcards should be marked as "available" automatically. In the later case, they should not be marked unless the CtCap confirms it (which at the moment isn't possible) or the remote rule recognizes the peer and sets the field (possible with SETFIELDOPTIONS()). > So rather than changing that behaviour in general, I suggest (again) > to do it by script. To make that possible, I added a new function > SETFIELDOPTIONS(). See patch suggestion below (as last time - compiled > but not functionally tested) Makes sense. However, I suggest we also add setting the "compare" and "merge" field attributes and GETFIELDOPTIONS(). I could have used that to switch from the default "compare calendar properties" mode to "compare UID", without having to write a compare script. > > For syncing between identical peers (as in > > SyncEvolution<->SyncEvolution, my other use case) I suggest that we > > generate CtCap with a "X-*" entry (yes, with wildcard) and do a strict > > string comparison also for wildcard props when analyzing CtCap. > > I guess just implicitly marking the "unprocessed" array field > available gives the same result, and also has the potential to at > least capture extra properties from other clients. Does it have to be marked as "available" to be used when parsing? -- 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
