Hello Patrick, On Dec 9, 2009, at 14:21 , Patrick Ohly wrote:
> 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. Agreed. The samples are derived from our iPhone client's, which is to date the most complete implementation (and so far the only client using iCalendar 2.0). > 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. Yes. > 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? Yes - I think well documented special cases like these are a benefit for the sample, as they show advanced features. For someone who doesn't want these properties, the special case is simple to remove from the config. For someone who wants to do similarily advanced mapping, the example of how it's done for Evolution is useful. (But also see suggestion at the end of this mail...) > 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: > [...] > > 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. Yes. It was a design decision to not try to abstract the type definition completely from the datastore capabilities, simply because the interdependences are so many and so fine grain, and sometimes really irregular and heuristic. This means that the config was intended to be the glue between SyncML and the backend, which in turn means that each backend needs its own config. The "rule" mechanism was intended for allowing some flexibility at the SyncML end. So from a high level perspective, I think the way to go would be towards a config generator which is part of the application using libsynthesis when that applications needs to support variable backends. In SyncEvolution case, this generator could query the available backends by it's own methods for supported properties, and then programmatically generate <fieldlist> <mimeprofile> and <map>, for example from a plain list of property names (and a set of built-in templates defining how to lay out a particular property). If this generator was made such that it can also be used as a commandline tool, I think it would probably be more useful as an example than a too much blown up supergeneric XML config which essentially would be a kind of flattened representation of the config gerenator code. Of course, to make things at hand work, the "rule" thing will probably be sufficient for now. > The "rule" parameter be only be used for a "property", right? Yes. > 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. As "rule" was indended for implementing special (and sometimes weird) cases for some strangely behaving devices (I remember we added it for the P900) it kept the config readable, as it clearly separated weird from normal cases. And often the variants were not primarily necessary for enabling fewer or more enums, but usually for different logic in the way parameters had to be used to map values correctly, so the entire property definition was affected. > So the TEL definition really should be > defined like this to become suitable for the general profile: > > [...] Yes. > 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 is very similar to the <use ... variant="xy"> which is already there to select subprofiles. > 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? Yes, that's how it works now. Generally, I'd say extending the <property> "rule" concept to something more generic would be useful, especially with a future separation of the vXXX encoder/decoder from the SyncML engine in mind. My suggestion would be to create a "condition" attribute for <property> that works the same way, but would allow expressions referring to remote rules, session variables and some special tokens like "datatype", so a condition could be <property condition"datatype=vCard30Evolution">. > 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". As SyncEvolution currently is THE app using libsynthesis, I think it would make much sense to have the current SyncEvolution config in the libsynthesis samples. On the other hand: why not just make it two sample configs, and name them such that it is clear yours has SyncEvolution dependencies, and the other is more generic, but probably less advanced? Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
