On 23/05/2014 13:02:04, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
As a reminder, we agreed on some aspects:
* Better explain what local sync is and how it involves two sync
configs. "originating config" gets introduces instead of just
* "data source" -> "datastore"
* Better explain the relationship between contexts, sync configs,
and source configs ("a sync config can use the source configs
the same context").
* An entire section on config properties in the terminology
* Less focus on conflict resolution, as suggested by Graham.
* Remove the hard-coded "target-config" name. It still needs to
there as fallback for existing configs or users continuing to
use the current instructions.
I'm personally not so keen on the last
one anymore. I agree it's
arbitrary, but it's just convention-over-configuration, and there's
already so much to configure in SyncEvolution.
I had also proposed to revise some of the magic that --configure does
when setting up a new config. I'm backing off of that and want to keep
the behavior as it is at the moment, because I am not sure how some
things should work without that magic.
That's OK I think, as long as we can
document that magic so it's
behavior is predictable.
Here's the list of changes made since I first proposed the
"datastore" avoids that misconception.
"data store" in two words could also have been used; not sure which
spelling is better.
I think "datastore" is better. As a single term,
is indicates a
SyncEvolution concept. As two words, it seems to indicate a more general
term that is not so tied to SyncEvolution.
Avoid "access a peer" when talking about a sync config, because
"access" implies that sync is initiated using the sync config,
is not the case for SyncML server sync configs in a
sync. "talk with peer" is more neutral.