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