On 13/04/14 19:45, Heyns Emiliano wrote: > In addition to this we have 1a: Target-Configs. I think a target-config > is really what binds two Sync Specifications together to form a full > sync pair, but I've lost track how; the syncURL seems to play an > important part here, but it has differing usage, sometimes it's used to > hold a real syncURL (such as > https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google), > another time it's use to point to something inside the syncevolution > config (such as local://@Context). It does feel a bit like a > target-config is only a 'kind of' Sync Config/Peer because the required > data could be shoe-horned into its data-structure, rather than there > being real similarity in intended behavior of these two kinds -- I > wouldn't mind to be corrected on this one.
If we put aside the special case of using target-config with things like --print-items, then I think target-config makes some sense to me... If you were syncing two different systems each running SE, using SyncML, then on each server you would have to set up a peer to point to the other side. One of them would have the syncUrl to make the outbound connection with, the other would have information to route the incoming connection to a particular sync-config and context. That makes sense to me. If we then consider a local connection, I think of that as just an optimisation of the connection. It seems logical that you still need a peer set up in each of the two contexts which are going to be connected together. One has the syncUrl (local://@context), the other doesn't actually need anything really but still exists and has to have the name target-config@context. That is why I would quite like to see the special name (target-config) go away and the local URL extended to specify any peer name you choose. But that is not how it works today. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
