On Thu, Apr 17, 2014 at 1:46 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:

> >I'm not sure I fully understand the question. Do you mean, "can
> >SyncEvolution figure out whether a sync config is for a client or
> >server"?
> No, I mean: can a sync config appear both as a client or as a server
> without any change to its properties?

The target config might be (mis)used like that: set
syncURL=bt-obex://... and sync with it -> it acts as SyncML server.
Point to it elsewhere with syncURL=local:// -> it acts as SyncML client
with a different peer.

This is a special case, though, and not intended. In general, a sync
config has exactly one role.


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.

I'm not saying the implementation should change, or that the command line should change. I think these are distinguishable objects. They need not to be distinct implementations, storage-wise (the behavior already is different, or no configuration errors could be thrown).
 
>  If so, "what it is" is ambiguous
> until it's used. If it is not ambiguous until it's used, it implements
> storage for an identifiable class of objects, which do different things
> (clients and servers do different things), so should be named
> differently.

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. Between 'park bench', 'court bench' and 'bench', 'bench' is the ambiguous term.

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? I though the originating config was usually a server that initiated the sync? If there indeed is not client or server, in the sense that these are simply equal pairs and that SyncML is intrinsically a peer-to-peer system, in which one peer is simply the originator, then I would understand. It's just that I thought that a SyncML session always did have a clear server and client.

Emile