On Wed, 2014-04-16 at 20:21 +0000, Heyns Emiliano wrote:
> >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.
"sync config" has to be fairly generic, because sync configs are used
for all kinds of things:
* Syncing with SyncML clients.
* Syncing with SyncML clients.
* The two sides in a local sync.
* To store username/password once for several other sync or source
configs (see "id:<name of config with credentials>" in the NEWS
file).
Suggestions for a better name are welcome.
> >-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.
I'm fine with introducing a separate term for this, but it needs to be
something that fits. My own best idea was and still is "per-peer store
properties".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
