[adding the list back]

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".

> There's no way how the "unprocessed" array can become available at all
> now, even if they are listed in CTCap - there's no match for wildcards
> in the CTCap scanning (and would not make much sense, IMHO).

Indeed, tricky. I'm not sure what a solution would look like that works
in all cases. There's simply no perfect match between "I support X-*"
and "you support X-FOOBAR".

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.

This is something for later. Needs more testing to ensure that we don't
confuse any of the other peers, for example. At the moment, I have
show="no" in our config for the "X-*" property.

-- 
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