On 17/04/2014 11:01:24, "Patrick Ohly" <[email protected]> wrote:
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).
But that's the thing. So we have 4 (I guess... one of the first two
would be "server" yeah?) entirely different concepts, that just happen
to store their properties in a fairly generic dictionary-type object.
What these 4 identifiable things mean is entirely separate from the
implementation detail of how they are stored internally.
Suggestions for a better name are welcome.
I don't think a single name will do. Much like 'target-config' has a
very specific conceptual meaning that is not covered by the way it
happens to be stored.
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".
I'm fine with that. Are these used for anything but a sync though?
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
