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:
>
>
> delayedparsing="1">
>
>
>
>
>
>
>
> 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 and
, 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:
>
>
>
> 3.0
>
>
This is very similar to the which is already there to
select subprofiles.
> This has one implementation problem: only one rule can be active at
