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 _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
