On Fri, 2011-06-24 at 20:37 +0200, Patrick Ohly wrote: > > > 1. sync config (used for syncing, contains the relevant "sync" mode > > > for sources) + target config (referenced by a sync config in > > > local:// syncURL) > > > 2. local config (uses local databases) + target config (referenced > > > by a sync config in local:// syncURL) > > > 3. sync config (used for syncing) + source config (use for > > > accessing the sources) > > > 4. client config (uses templates for clients) + server config > > > (accesses the server) > > > 5. server config (acts as SyncML server) + client config (SyncML > > > client) > > > > I've thought of them as "local config" and "remote config". > > That makes sense only for a subset of the use cases. "local sync" was > already used to synchronize between EDS (in the sync config) and files > (in the target config), in which case "remote config" doesn't quite > fit. > > > But I > > suppose "sync" and "target" would work too. > > Okay. Given that we seem to settle on "sync" and "target", should we go > all the way and not only use these terms in the configuration, but also > in the actual config names? In other words, replace "source-config@foo" > with "target@foo"?
Let's do it... done. Note the typo above: the expected config name is now "target-config@<context>". commit 8032247a5a004303cac5969b76a126b98fa298ef Author: Patrick Ohly <[email protected]> Date: Tue Jun 28 18:42:43 2011 -0700 local sync: renamed "source-config" to "target-config" As discussed on the mailing list, "source-config" is ambiguous because the "addressbook/calendar/..." configs are also called "source configs". Now the naming is "sync" config (for the config with syncURL=local://, because it is used for syncing) and "target" config (because it is used as target in a sync config's syncURL). Rejected: "local" config - because the databases are not necessarily local "source" config - see above "client" or "server" config - because both sides might use local data and/or client/server could refer to the role of the peer or the SyncML client/server model used internally -- 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] http://lists.syncevolution.org/listinfo/syncevolution
