2:01 a.m.
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.
>> 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".'
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.'
Anyway, thanks for taking the time to consider my comments.
Graham