On Fri, 2014-04-11 at 16:52 +0200, Patrick Ohly wrote:
[<property name="UID" rule="HAVE-VCARD-UID"> shows up in CtCap]
> Could it be a bug that the disable property shows up in the CtCap?
>
> Darn, probably a circular dependency again: we have to be ready to send
> CtCap before we know the peer, so the rule mechanism (which depends on
> knowing the peer) can't be used to influence the CtCap. Right?
A closer look at the CtCap seems to confirm that. For example,
SyncEvolution knows that KDE uses X-KADDRESSBOOK-X-Profession instead of
ROLE, so it has:
<!-- X-KADDRESSBOOK-X-Profession property for KDE, ROLE for everyone
else -->
<property name="ROLE" rule="KDE"/>
<property name="ROLE" rule="other">
<value field="ROLE"/>
</property>
<property name="X-KADDRESSBOOK-X-Profession" suppressempty="yes"
show="no" rule="KDE">
<value field="ROLE"/>
</property>
This is a somewhat convoluted way of saying that vCard ROLE is not
active for KDE (no "value" specied) and that X-KADDRESSBOOK-X-Profession
is to be used instead.
In the CtCap, both properties show up:
<Property><PropName>ROLE</PropName><MaxOccur>1</MaxOccur></Property>
<Property><PropName>X-KADDRESSBOOK-X-Profession</PropName><MaxOccur>1</MaxOccur></Property>
This means that I can't put properties that are never meant to be sent
over SyncML into the profile used for syncing. I need to maintain a
separate profile with UID enabled that gets used for
MAKETEXTWITHPROFILE/PARSETEXTWITHPROFILE.
I wonder whether it makes sense to have X-KADDRESSBOOK-X-Profession
appear in the CtCap. Probably not, because SyncEvolution will not use it
during syncing, only during storing in the datastore. I probably need to
change the way how SyncEvolution adapts the main profile for specific
storages: instead of setting rules in MAKETEXTWITHPROFILE or
PARSETEXTWITHPROFILE, it needs to do its own custom pre-processing to
turn the main profile into a "KDE" profile or an "EDS" profile.
--
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
