On Thu, 2014-04-10 at 15:31 +0000, Emiliano Heyns wrote:
> On 10/04/2014 12:11:34, "Patrick Ohly" <[email protected]> wrote:
>
> >> >and two sync configs representing peers (P1@Ctx, P2@Ctx). Then
> >> >there are a a bunch of objects as in this matrix:
> >> In which, just to see if I understand this correctly, P1@Ctx
> >>describes
> >> how peer P1 can access S1/2/3.
> >
> >The full line for P1@Ctx describes how P1 syncs:
> P1 here is a peer then, and P1@Ctx (aka a sync config) describes within
> Ctx exhaustively how P1 can sync in Ctx? Or could a single peer
> (sensibly) have multiple of these within a single context?
Both works for syncs initiated by the user of SyncEvolution. When
SyncEvolution acts as SyncML server, the protocol forces us to have a
single sync config for the SyncML client with all sources enabled that
it is meant to have access to.
Apart from that there's nothing wrong with having different sync configs
for the same peer, whether it is in the same context or in different
ones. The original goal was to have just one sync config (say, "google"
instead of "google-contacts" and "google-calendar") because it allows a
single command to sync all data of that peer ("syncevolution google" vs.
"syncevolution google-contacts && syncevolution google-calendar");
ultimately that's up to the user.
Side note: traditionally, a SyncML session (and that includes a local
sync) allows multiple sources to be synced at once. For SyncML over HTTP
that has some performance benefits (less message exchanges in particular
when no data needs to be transferred), but it also increases the
complexity of the sync considerably. I am contemplating to run syncs
under the hood such that only one source is active at a time. See
https://bugs.freedesktop.org/show_bug.cgi?id=57004. However, for the
user nothing would change (the "syncevolution google" command would
still sync all active sources, just one after the other) and thus the
current discussion is not affected by this implementation detail.
> >the Xmn boxes describe
> >how it access the respective source (basically the "sync" mode) and the
> >last column has the sync properties for the peer.
>
> So: P1@Ctx has sync config properties that describe all relevant sync
> properties for the peer except the sync mode of that peer with any
> single data source within that context, which is held by the Xmn entity.
> If so, for the sake of current discussion, I would propose to call that
> SyncMode.
"uri", "syncFormat" and "forceSyncFormat" also fall into the same
category. Calling them "SyncMode" isn't really appropriate.
> >From the perspective of the configuration system, "target-config" is
> >just another sync config and thus another line in the diagram. Nothing
> >stops you from setting a "sync" property in one of the Xmn boxes. But
> >these values are not used and therefore don't make sense there. Perhaps
> >this can be visualized like this:
> >
> But above you said that Xmn specifically holds the "sync" mode. Is this
> different from the "sync" property?
No, it's the same thing. With sync mode I meant the value of the "sync"
property: one-way, two-way, etc.
> My data visualizing skills are non-existent, so I've resorted to the
> only tool I know in this domain: SQL. Could you guys have a look at
> http://reichenhack.github.io/syncevolution-model.html to see if this is
> going somewhere?
"forceSyncFormat, sync, syncFormat, uri" are not placed correctly in
that model at the moment. Other than that this looks right.
--
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
