8:20 a.m.
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.