------ Original Message ------
From: "Patrick Ohly" <[email protected]>
To: "Emiliano Heyns" <[email protected]>
Cc: "Ove Kåven" <[email protected]>; "SyncEvolution"
<[email protected]>
Sent: 17-4-2014 17:11:41
Subject: Re: [SyncEvolution] Getting the concepts clear (Was:
Configuring a target)
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").
OK, but that description of the config mechanism is only going to figure
once, in an abstract sort of way. The only reason why a user would
engage with the config layer is to express in properties something that
has meaning on the engine layer. The configuration layer can for the
end-user only be understood in terms of what it allows one to do at the
engine layer. It is this layer I want to focus on.
Note that I'm not at all saying that the config layer is of no
importance, or that I think we must at any cost do away with the sync
config terminology. I just think that we also need
functionality-oriented terminology, describing what one can do with the
engine layer if one manipulates the config layer in a certain way. But I
want to explain to the user what must or can be done conceptually,
before I explain technically how it must or can be accomplished.
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)?
So perhaps the naming could be better, but naming it simply "sync
config" tells me less, not more. Assuming SyncML is client-server, and
not peer-to-peer, the case you describe here could mean several things
for me:
1. A SyncML server configuration on the phone, and a SE SyncML client
configuration on the PC (assuming we're talking about SE running on a
PC)
2. A SyncML client configuration on the phone, and a SE SyncML Server
configuration on the PC
So as long as we're assuming we're setting up SE stuff, SyncML client
config would be unambigous. If we besides these 2 want to register the
properties of an non-SE SyncML client (let's say we want to register the
settings for the on-phone SyncML client on SE -- why would we want to do
this?), how we would name this would depend on what role this
configuration would play in actual use.
What I do know is that calling all these 3 simply "sync config" makes
understanding what's going on (much more) harder, not easier. If I were
to say "now we set up the sync config", how would we know which of these
3 I'd mean? If we say "now we set up a sync config that describes the SE
SyncML server for...", that's meaningful, but then that's exactly the
conceptual level I'm aiming for. I don't by any necessity need whole
ranges of new concepts to be introduced; these roles can be descriptive
and wordy if need be.
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?
I viewed it in a fixed-width font at some point. But all this gives me
is a kind of class inheritance chart. It says nothing about how I can
expect instances of these classes to behave or relate with one another.
What does a target-config target, or is it instead targeted at? Can a
'config-thing' be expected to have any behavior at all? In my mind,
'configs' are descriptions, perhaps of actors, but they are not actors;
peers, clients and servers can act, and configs can describe their state
at any given point in time. If we're talking about peers, and there's no
clients or servers, are peer-pairs always on a par with each other, with
no discernible role, as in serverless peer-to-peer systems like
mutualcast? Because that is what peer without further qualification
means.
That it is also the config of a SyncML server is an implementation
detail.
That I agree on.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
