Den 13. april 2014 20:45, skrev Heyns Emiliano:
Another run to see if I have my concepts straight.
Frankly, it amazes me to see how much effort it takes to get even the relatively simple parts of this through. But then again, perhaps the problem is that you are trying to understand the simple concepts in terms of the more complex stuff that's layered on top, instead of the other way around, trying to understand the simple stuff first, and only then try to understand how the complex stuff is layered on top.
So, to hopefully relieve Patrick a little, I'll try to explain briefly what it's all about, from the top.
SyncEvolution is, at its core, a SyncML synchronization engine. Anything the engine wants to synchronize with *must* talk SyncML, no exceptions. That's what a sync config is meant to do: the syncURL says which SyncML server to talk to, the uris specify which databases on that SyncML server to synchronize each source with, and so on. (Note that there's no target-config, just a single sync config, or peer config or whatever you want to call it.)
But what if the server you want to talk to isn't a SyncML server, but a WebDAV or ActiveSync server? How is that possible, if SyncEvolution must talk to something that understands SyncML? But wait, SyncEvolution itself understands SyncML, and can act as server! We can just have SyncEvolution talk to itself! A big hack, but it solves the problem.
To do that, the original sync config's syncURL would no longer point to a remote SyncML server, but, by using "local:", it can be set to point to a local SyncML server within SyncEvolution itself, using a different configuration context. For simplicity, that SyncML server is always called "target-config", though it's otherwise just a completely normal sync config, nothing special about it configuration-wise. It's just the peer that SyncEvolution talks to internally when it's asked to talk to itself.
Then the sources for that target-config can, instead of accessing local databases, be configured to use special backends which can access remote (non-SyncML) databases, such as WebDAV or ActiveSync.
And that's all the functional pieces you need for a complete non-SyncML sync solution. What's left is just the details of how to shoehorn this solution into a configuration system that wasn't originally designed for this huge hack (rather, just kind of evolved there while preserving backwards compatibility), and we're golden.
A context contains 3 "kinds" of entities: 1. Sync Configs, which roughly correspond with entries in the directories called 'peers' in the config directory. I think 'peer' is a better name for what I think these do, BTW: they seem to be geared to specifying how a remote 'side' (be it a device, a service, etc) can be reached, broadly.
I'm not entirely sure you should call it peer, because then "target-config" would also have to be called a peer. That stuff is probably why Patrick likes to separate the concepts of "peer" and "sync config" (it wouldn't make sense to say that a WebDAV server is two peers, when physically there's only one WebDAV server).
2. Source Configs, which roughly corresponds with entries in the directories calls 'sources' in the config directories. I think 'source' is a good name for these. A source describes a database, with relative to a yet to be named peer.
Not typically. The source config may contain everything needed to access a particular local or remote database (as long as that remote database is not SyncML), completely independently of any peer.
Only in some cases, if a property is not explicitly specified in the source config, then SyncEvolution may default to a corresponding property from the sync config. For example, in a WebDAV configuration, if database is not specified, then syncURL may be used, if databaseUser is not specified, then username may be used, and so on. (That's a convenience feature implemented in the WebDAV backend, though, not the configuration system itself. It is not necessary.)
(Incidentally, because the WebDAV backends are normally configured on the target-config (SyncML server) side, then this means that the WebDAV url and username can usually also be specified in the target-config, instead of explicitly in every source.)
It seems possible that a source could be used in combination with different peers, but all the examples I've found so far seemed to assume that a source was set up with a specific peer in mind; as such, it seems like in practice there is an hierarchy context-peer-source.
I suppose that's because they're examples (and perhaps also not written by SyncEvolution experts). You could share a source among several peers if, for example, you had several cell phones you wanted to sync your local addressbook with.
On a different tack, I am slowly starting to figure out what the various command line calls mean in the HOWTOs that are available, and the scripts that I've assembled, but this one still eludes me: syncevolution --configure sync=two-way uri=calendar Exchange@Local calendar From what I can gather, this sets the properties on Xmn entries (because only Xmn have these properties). But Exchange and Local are contexts;
"Exchange" is a peer within the context "Local". No ambiguity here. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
