On 23/05/2014 13:02:04, "Patrick Ohly" <[email protected]> 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
"sync config".
* "data source" -> "datastore"
* Better explain the relationship between contexts, sync configs,
and source configs ("a sync config can use the source configs
in
the same context").
* An entire section on config properties in the terminology
section.
* Less focus on conflict resolution, as suggested by Graham.
* Remove the hard-coded "target-config" name. It still needs to
be
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 revised
README.rst:
"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,
which
is not the case for SyncML server sync configs in a
client-initiated
sync. "talk with peer" is more neutral.
Agreed.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
