On Mon, 2014-04-14 at 00:20 +0200, Ove Kåven 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.
Thanks, that's useful and spot on. I just have some very minor corrections and some anecdotal additions. > 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. Indeed. It came to be out of lack for alternatives (defining and implementing an entirely new sync protocol is no piece of cake), but it does the job pretty well (IMHO). I had to extend the sync engine occasionally (see PBAP and the new caching sync modes) and may have to do it again, but that was still less work than starting from scratch. > 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. Actually, the originating side acts as SyncML server and the target-config as client, hence the "peerIsClient=1" in the originating side. The property has to be set because at some point it might make sense to allow reversing the roles. If that happens and configs are in use where the property is not set, we wouldn't be able to use it. The reason for making the local side the SyncML server is that this role needs to talk with the database more often. It is faster to do that on the side that (usually) has the real local databases. > > 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). Correct. "Peer" is such a fuzzy term. I couldn't avoid it entirely due to lack of alternatives, though (see that "peers" directory, "peerIsClient", "per-peer" config properties, etc.). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
