On Thu, 2014-04-17 at 14:16 +0200, Emiliano Heyns wrote:
> In other words: sync configs are more often than not used in
> identifiable roles, and even where a single config could be used in
> more than one role, it is nearly always set up with a specific role in
> mind. To me, that makes these roles identiably different
> 'things' (classes if you will), regardless of whether they share an
> implementation mechanism. The terms "server" and "client" are
> meaningfully different, even if both can be configured using the same
> dictionary-like object, and I feel that conceptually it would be best
> to distinguish them. By inspecting the configs, SE can even tell you
> when you are configuring it 'wrongly' for a given role; that is not
> the behavior of an amorphous "bag of properties", but of something
> that understands its purpose.
Beware of the of the two layers in SyncEvolution:
1. Configuration layer.
2. Engine layer.
At the configuration layer, SyncEvolution only knows about sync and
source configs (current terms). It has no way of doing any semantic
checks.
The engine layer is where something in SyncEvolution tries to use these
generic configs. This could be a backend (for source configs) or the
sync engine (for sync configs), at which point it becomes possible to
identify mistakes.
So when describing the configuration mechanism, one has to use the
generic terms ("setting up a sync config"). When applying that mechanism
for specific use cases, the more descriptive terms come into play
("setting up a SyncML server config").
> One can have a hierarchy of terms:
>
> peer config
> / | | \
> / | | \
> SyncML client config | | SyncML server config
> | |
> | target config
> originating config
>
> I'm using "client/server config" here to illustrate the point.
> I'd
> prefer to not introduce them because of the ambiguity.
>
> But in what sense are these ambiguous? To my mind, client/server tells
> me something about their role; to call them both 'config' would be
> ambiguous.
It's ambiguous when talking about the phone and the PC at the same time.
When saying "the SyncML client config", is that a config on the phone
(because it is the client) or on the PC (because we set up a config for
the client there)?
> I am not convinced that we really need separate terms for
> SyncML sync
> configs. "sync config" works for me, with originating and
> target config
> as special cases of that.
>
>
>
>
> But keeping with this naming for a second, the originating config is a
> client config?
The line in my ASCII diagram goes from "originating config" to "peer
config". Perhaps that wasn't obvious when viewing with variable width
font?
That it is also the config of a SyncML server is an implementation
detail.
--
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
