5:33 a.m.
On Thu, 2014-04-10 at 19:19 +0000, Emiliano Heyns wrote:
On 10/04/2014 21:03:05, "Patrick Ohly"
<patrick.ohly(a)intel.com> wrote:
>On Thu, 2014-04-10 at 15:31 +0000, Emiliano Heyns wrote:
>> On 10/04/2014 12:11:34, "Patrick Ohly" <patrick.ohly(a)intel.com>
>>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.
OK, given this then, "peer" and "sync config" are different concepts.
Correct, and the terminology section describes them as different things,
too.
A
peer can have multiple sync configs, and a peer loosely translates to a
device or service or other syncml instance,
Correct.
but is merely a notational
convention to mentally cluster several sync configs. Correct?
I wouldn't describe it like that. A peer typically really exists in the
physical world, so it is more than just an abstract convention.
>> >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.
>
OK, I've moved them and simply renamed that entity to SyncSource for
now. The 'sync' property is currently located on the DataSource -- that
is still correct?
No. What you had is "mode" in "SyncMode" is the "sync"
property value.
>> >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.
So this 'sync' property is then not part of Xmn (which I dubbed
SyncSource for now), but of the data source.
The "sync" property lives in the intersection of data source and sync
source, so it *is* part of Xmn. I would even say that it is the most
important part of it, although there are others ("uri", "syncFormat"
and
"forceSyncFormat").
--
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.