I appreciate the extra info, but not so much the implication that I'm hard to deal with. The documentation might be meaningful to people deeply knowledgeable about syncevolution and its internals. For people trying to get up to speed, they're a disaster. Damn right it's amazing how much effort it takes to get the simplest of things figured out - and not just Patrick's, mine too.
It took what, weeks? for Graham to stumble upon the xmn idea. Without that the documents don't make any kind of sense. Even to figure out what counts as simple and complex is damn hard to figure out from the documentation. I'm sorry if this has been a burden on Patrick. It hasn't exactly been a picnic for me, either. I have a master's degree to finish, a family to tend to, and a full time job. I have an irrational thing for open source which makes me put time into things like this instead of just fiddling with the settings until it works for me, but instead I try to figure out the conceptual mess spread throughout the docs so I can tie them together so others after me don't have to. My master's is philosophy. I am used to tying together complex concepts. What I'm not used to is a mishmash of ambiguous terms, silent defaults and position bound parameters, of which I should just hope that Patrick and others don't make any typos, because that just puts me hopelessly off track again. Most of all, I'm not used to having to tiptoe around people's feelings while I'm trying to clarify ambiguities. Bugger this for a lark. If syncevolution as a project thinks the documents are fine as-is, and anyone that can't silently muddle through them is dense, there's nothing useful I have to offer. On Apr 14, 2014 12:20 AM, "Ove Kåven" <[email protected]> wrote: > 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@Localcalendar >> >> 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
