Hello!
We've discussed how XML example configs can be shared between projects
and client/server (split up into fragments). There's one more aspect
related to this which I would like to bring up: which properties should
be supported by the example profiles and field lists?
I think the examples should be as complete as possible. This way the
Synthesis "contacts" and "calendar" field lists have a chance of
becoming the "lingua franca" when converting to and from different
flavors of vCard/vCalendar/iCalendar. Likewise, the example profiles
should explain how this maps to those different flavors.
Now it gets a bit more complicated. What we want is "one profile per
flavor", but that is hard to manage. The approach currently taken in
SyncEvolution is to enable or disable properties based on an "EVOLUTION"
rule. Here's an example, made a bit more complex because it handles both
X-MANAGER and X-EVOLUTION-MANAGER when talking to the peer:
<!-- item for SyncML server: EVOLUTION rule not active,
both X-EVOLUTION-MANAGER and X-MANAGER are sent.
item from SyncML server: EVOLUTION rule not active,
both X-EVOLUTION-MANAGER and X-MANAGER are checked,
but X-EVOLUTION-MANAGER later so that it overwrites
a value set earlier by X-MANAGER (if any). This is
a more or less arbitrary priority, chosen because
servers that know about SyncEvolution (ScheduleWorld,
Memotoo) use the X-EVOLUTION variant.
item to/from Evolution: EVOLUTION rule is active,
only X-EVOLUTION-MANAGER is used. -->
<property name="X-EVOLUTION-MANAGER" suppressempty="yes"
delayedparsing="1">
<value field="MANAGER" show="yes"/>
</property>
<property name="X-MANAGER" suppressempty="yes" rule="EVOLUTION"/> <!--
disables the X-MANAGER for EVOLUTION -->
<property name="X-MANAGER" suppressempty="yes" rule="other">
<value field="MANAGER" show="yes"/>
</property>
Is something like this acceptable in the upstream libsynthesis samples?
Another, unsolved problem is how a local datastore specifies which of
the properties it really supports. For example, suppose we use the full
sample profile, including entries like this:
<property name="TEL">
<value field="TEL"/>
<position field="TEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="TEL_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<enum name="VOICE" value="B3"/>
<enum name="CELL" value="B4"/>
<enum name="FAX" value="B5"/>
<enum name="PAGER" value="B6"/>
<enum name="PREF" value="B7"/>
<enum name="CAR" value="B8"/>
<enum name="X-EVOLUTION-CALLBACK" value="B9"/>
<enum name="X-EVOLUTION-RADIO" value="B10"/>
<enum name="X-EVOLUTION-TELEX" value="B11"/>
<enum name="X-EVOLUTION-TTYTDD" value="B12"/>
<enum mode="prefix" name="X-CustomLabel-" value="1.L"/>
<enum mode="prefix" name="X-Synthesis-Ref" value="2.L"/>
</value>
</parameter>
<parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="yes">
<value field="TEL_SLOT"/>
</parameter>
</property>
Strictly speaking, X-Synthesis-Ref should not be listed when this
profile is used by SyncEvolution. It doesn't have an effect in this case
only because "mode=prefix" does not get reflected in the DevInf
generated from this profile. Other extensions to parameters and
properties would show up, giving the wrong impression to a SyncML peer.
The "rule" parameter be only be used for a "property", right? It cannot
be used for a more fine-grained control over what parameters a shared
property contains. That might be the right tradeoff between sharing
definitions and complexity. So the TEL definition really should be
defined like this to become suitable for the general profile:
<property name="TEL" rule="SYNTHESIS">
<!-- TEL property as supported by Synthesis clients -->
<value field="TEL"/>
<position field="TEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="TEL_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<enum name="VOICE" value="B3"/>
<enum name="CELL" value="B4"/>
<enum name="FAX" value="B5"/>
<enum name="PAGER" value="B6"/>
<enum name="PREF" value="B7"/>
<enum name="CAR" value="B8"/>
<enum mode="prefix" name="X-CustomLabel-" value="1.L"/>
<enum mode="prefix" name="X-Synthesis-Ref" value="2.L"/>
</value>
</parameter>
</property>
<property name="TEL" rule="EVOLUTION">
<!-- TEL property as supported by Evolution -->
<value field="TEL"/>
<position field="TEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="TEL_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<enum name="VOICE" value="B3"/>
<enum name="CELL" value="B4"/>
<enum name="FAX" value="B5"/>
<enum name="PAGER" value="B6"/>
<enum name="PREF" value="B7"/>
<enum name="CAR" value="B8"/>
<enum name="X-EVOLUTION-CALLBACK" value="B9"/>
<enum name="X-EVOLUTION-RADIO" value="B10"/>
<enum name="X-EVOLUTION-TELEX" value="B11"/>
<enum name="X-EVOLUTION-TTYTDD" value="B12"/>
</value>
</parameter>
<parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="yes">
<value field="TEL_SLOT"/>
</parameter>
</property>
<property name="TEL">
<!-- default TEL, supporting all known parameters -->
<value field="TEL"/>
<position field="TEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="TEL_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<enum name="VOICE" value="B3"/>
<enum name="CELL" value="B4"/>
<enum name="FAX" value="B5"/>
<enum name="PAGER" value="B6"/>
<enum name="PREF" value="B7"/>
<enum name="CAR" value="B8"/>
<enum name="X-EVOLUTION-CALLBACK" value="B9"/>
<enum name="X-EVOLUTION-RADIO" value="B10"/>
<enum name="X-EVOLUTION-TELEX" value="B11"/>
<enum name="X-EVOLUTION-TTYTDD" value="B12"/>
<enum mode="prefix" name="X-CustomLabel-" value="1.L"/>
<enum mode="prefix" name="X-Synthesis-Ref" value="2.L"/>
</value>
</parameter>
<parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="yes">
<value field="TEL_SLOT"/>
</parameter>
</property>
Now the "unsolved" part: there is no mechanism that activates the
"EVOLUTION" or "SYNTHESIS" rule when using the profile with a peer. The
existing mechanism activates rules based on the *peer*, not the local
datastore. Would an extension for the XML config work? Perhaps like
this:
<!-- vCard 3.0 datatype in Evolution, using shared vCard profile defined
above -->
<datatype name="vCard30Evolution" basetype="vcard">
<version>3.0</version>
<use mimeprofile="vCard" rule="EVOLUTION"/>
</datatype>
This has one implementation problem: only one rule can be active at a
time. We might start with the EVOLUTION rule being activated by the XML
config, but then after identifying a peer, that peer's rule would
overwrite the EVOLUTION rule instead of adding a second one. Is my
recollection of how the code works correct?
In order to get the different configs in sync right away, I could merge
the recent changes made by Lukas with our own extended config, then push
that back without adding such extra "rule" parts. It would make the
samples unusable for anyone except SyncEvolution, though, because of
extensions like "X-EVOLUTION-UI-SLOT".
Comments?
--
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
