------ Original Message ------
From: "Patrick Ohly" <[email protected]>
To: "Emiliano Heyns" <[email protected]>
Cc: "Todd Wilson" <[email protected]>; "Graham Cobb"
<[email protected]>; "SyncEvolution"
<[email protected]>; "Ove Kåven" <[email protected]>
Sent: 16-4-2014 22:05:27
Subject: Re: documentation update, enhanced command line
First we reach consensus on key terms. Contentious (or at least not
explicitly accepted) are:
* "originating source" in a local sync (proposed by me).
* "source" vs. "store" (I think both Todd and Emile preferred
store).
* "Client Endpoints" instead of "sync configs" (Emile)
* "Synced stores" as new term for the per-peer source properties
(Emile)
The next phase then would be to pick the exact wording for README.rst,
using these agreed terms. We should do this using git commits in actual
repos, to facilitate merging and change tracking. If someone wants to
propose new text for the README.rst, please clone the new "doc" branch
in http://cgit.freedesktop.org/SyncEvolution/syncevolution/?h=doc and
post patches in "git format-patch" style to the list. Optionally also
push the updated git tree somewhere (github?), in particular if it
involves merges.
All for this.
I've push my own proposal there, but it is not final because I think I
will pick up more of your proposals once their is consensus on terms.
Regarding the new terms, here's my position:
+1 for "originating source". I think it is needed.
I'm perfectly fine with this. I currently understand this to cover, a.o.
a server-initiated sync as implemented in the target-config setup. I'll
go through the README.rst again and update my explanation accordingly.
+1 for "store" instead of "source". I agree with Todd's explanation
that
the source incorrectly implies a data direction.
Agreed.
-1 for "Client Endpoints". This is misleading because the same thing is
also needed for servers. "sync config" covers both because it is
neutral.
I am entirely open to ditching client endpoints. I feel iffy about 'sync
config' because it is so generic; it doesn't really disclose anything
except 'it does something with sync' -- but then, everything of
syncevolution does something with sync.
-1 "Synced stores". This just doesn't sound right to me, but I cannot
quite nail why. Perhaps because I simply don't think of this as real
entities, just as some additional settings for a source (or soon,
store).
I hate the term myself, so no complaints on replacing it. If it stays as
a property of a store (BTW, this was explained earlier as a property of
the "sync config", not the store), the best way to describe it would be
"a dictionary of which the keys must exist as a store in the same
context". As the keys of this dictionary have constraints, and the
values of this dictionary have properties that depend on them, I think
their behavior is complex enough to warrant existence. Specifically, the
matching that happens in the setup of target-config et al gets confusing
if we deny these exist.
Regards,
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
