On Thu, Apr 17, 2014 at 1:46 PM, Patrick Ohly <[email protected]>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
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
