On 15/04/2014 12:14:15, "Patrick Ohly" <[email protected]> wrote:
I suspect that running SyncEvolution as SyncML client is still more
common (and thus "normal") than running it as SyncML server. For the
sake of this discussion, "normal" sync is both, because it involves
only
one sync config.
OK, once more then:
So in a 'normal sync', which I understand to be a sync between any given
syncml server and SE acting as a syncml client, only needs (minimally):
one or more data source, which is a full specification of a database
(kind: events, memos..., storage engine=backend+format, location:
database) to be synceda sync config, which in this case would point to
the remote syncml server, with minimally the username, password and
syncURL (pointing to the syncml server)
In such a case, SE in the role as a syncml client knows by the Xmn
entries associated through the sync config what sources it should offer
(what would happen if 2 'contacts' sources were offered?), and which way
the sync would go (two-way or one-way; is one-way a push?). SE as a
client initiates the sync.
EAS and WebDAV are not considered sync engine technologies within the
scope of SE, but data storage engines. While it would be in principle
possible to set up a pair of server-based backends, for simplicity and
debuggability, we set up a hub-and-spoke system with the hub a simple
backend such as the 'file' or 'eds' backends. The hub will be SE as a
syncml client as described above. The syncml client role uses the
syncURL local://@context to point out that it wants to connect to the
target-config in @context instead of a real syncml server.
The target-config specifies a faux syncml server, which (conceptually)
awaits the incoming connection. This incoming server must know what data
stores it has available; this is registered in its Xmn entries, which
point to data sources in its own context. The target-config+associated
source entries have the full specification to access the data stores; in
the case of a server-based store, this means that either the username
and password set in the target-config must be applicable to all the data
sources it is associated with, or the data source must itself provide
the correct username/password.
The SyncML client chooses which sources it wants to sync with. This is
what SyncEvolution as SyncML client does via the "uri" property, stored
in the Xmn entry that ties together the client side with the
target-config; the uri property points to a data source inside the
context that the target-config lives in. The data source pointed to in
the Xmn entry must match the kind of the data source pointed to by
uri@target-config-context.
After setting up, for example:
"client": context=C1, source=S1a of type 'contacts', S1b of type
'events', sync-config=SC1 with syncURL pointing to local://@C2, with Xmn
source=S1a+uri=S2a<@C2 implied>, source=S1b+uri=S2b<@C2 implied>
"server": context=C2, source=S2a of type contacts, S2b of type events,
sync-config=target-config with an irrelevant syncURL
I could --sync SC1@C1, and this would cause S1a and S2a to be synced,
and S1b and S2b to be synced
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
