On Thu, 2014-04-03 at 16:01 +0100, Graham Cobb wrote:
> On 03/04/14 14:50, Patrick Ohly wrote:
> > On Wed, 2014-04-02 at 15:20 +0100, Graham Cobb wrote:
> >> On 02/04/14 13:16, Patrick Ohly wrote:
> >>> configuration property
> >>> Sync and source configs contain configuration properties. Each
> >>> property is a name/value pair. Sync properties are used in sync configs,
> >>> source properties in source configs. The names were chosen so that
> >>> they are unique, i.e., no sync property has the same name as a source
> >>> property.
> >>>
> >>> A property can be *unshared* (has separate values for each peer,
> >>> therefore
> >>> sometimes also called *per-peer*; for example the `uri` property which
> >>> defines the remote database), *shared* (same value for all peers; for
> >>> example the `database` property for selecting the local database) or
> >>> *global* (exactly one value).
> >>
> >> I have found this confusing as well. To the naive view, per-peer
> >> properties should be sync properties, shared properties should be source
> >> properties, and global properties should be context properties.
> >
> > So you would change the meaning of "sync property" from "a property set
> > in a sync config" to "a property set for a sync peer"? That is indeed
> > close to how the properties are used, but does not match how the
> > implementation works. Changing the command line options would require
> > changing the implementation.
>
> Interesting. Maybe this is close to the root of my problem, because I
> don't understand how "a property set in a sync config" and a property
> set for a sync peer" are different. I will need to think about this
> when I have a bit more time.
With the current definition and implementation, sync properties are
independent of any particular source and thus can be addressed by just
giving the sync config ("foo@bar"). Source properties must be attached
to a source and thus require a source name when accessing them ("foo@bar
addressbook" for per-peer source properties, "@bar addressbook" for
shared source properties).
Internally the properties are maintained as two independent sets. It's
just by convention that there is no name overlap between the two sets.
That makes it possible to use the shorter "foo=bar" notation, because it
can be determined reliably whether "foo" is a sync or source property.
> >>> local sync
> >>> Traditionally, a sync config specifies SyncML as the synchronization
> >>> protocol. The peer must support SyncML for this to work. When the
> >>> peer acts as SyncML server, conflict resolution happens on the
> >>> peer, outside of the control of SyncEvolution.
> >>
> >> Is there some reason conflict resolution gets mentioned here? Does it
> >> really have anything to do with local sync?
> >>
> >>> In a so called `local sync`_, SyncEvolution connects two of its own
> >>> backends and runs all of the synchronization logic itself on the host.
> >>
> >> Again, why mention synchronization? Is there something important you
> >> are trying to convey?
> >
> > The key point is that it is SyncEvolution doing the synchronization,
> > putting it under control of the user. If there is a remote server
> > involved, for example an Exchange server, then we don't allow it to do
> > conflict resolution for us.
>
> I understand that that is true, but I still don't understand why you
> feel the need to mention it. It seems to be complicating the local sync
> concept needlessly.
>
> My suggestion for the local sync definition:
>
> 'Traditionally, a sync config specifies SyncML as the synchonization
> protocol. In some cases, the desired SyncML peer is actually another
> context on the same SyncEvolution system (for example, the user may wish
> to synchronize Evolution data with a file-based database on the same
> system). If the peers are on the same system, then SyncEvolution can
> work more reliably and efficiently by using its own, internal,
> mechanisms instead of actually using SyncML. This is called a "local
> sync".'
That's a step forward, but as you said yourself, it leaves the user
wondering how the other protocols fit into SyncEvolution. Instead it
emphasizes syncing real local data, which wasn't the main goal for local
sync.
> I believe that provides a full and useful definition of local sync.
> However, I think that in the original you might also have been trying to
> bring out the concept of how non-SyncML peers need to be handled. My
> suggestion is to take that out of the "local sync" discussion altogether
> and find somewhere else to put it. Not sure where, but maybe the text
> could look something like...
>
> 'SyncEvolution always uses SyncML to communicate with peers. No other
> protocols are supported directly for synchronisation (except the
> internal "local sync" optimisation used when the SyncML peer is on the
> same system). All other protocols (such as ActiveSync, CalDAV/CardDAV,
> Google, etc) are handled indirectly. In these cases, a SyncEvolution
> "backend" is used to allow these servers to be treated as database
> sources and to be made available over SyncML. SyncEvolution can then
> manage synchronisation between any combination of these servers and
> traditional SyncML devices.'
Can we use the local sync definition above together with this paragraph
to introduce local sync in the terminology section? It becomes a bit
long, but it's important to get this in front of users before anything
else.
--
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
