> Therefore I suggest that we change our configuration layout. Instead of > a "server configuration" directory, we start with a "host > configuration" (better names welcome!). I'd like to use 'global configuration' or something else since it may not only be 'host's settings'.
> Finally, the instructions for synchronizing multiple ScheduleWorld calendars > have to be updated. When setting up the second scheduleworld config, the name > of the "calendar" source is already in use and something > else must be used to avoid overwriting the "evolutionsource" > property in the existing source. What does 'the second scheduleword config' mean? I don't quite understand how to handle multiple configs for one syncML server in new scheme. If similar to previous, two configs are in 2 different directories, so why existing the above issue you raise? Cheers, Yongsheng -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Patrick Ohly Sent: Sunday, September 13, 2009 3:50 AM To: SyncEvolution Subject: [SyncEvolution] configuration + multiple peers Hello! Let's think about our configuration handling and how we are going to deal with multiple peers. Right now, we have one set of configuration files per server. Each server synchronizes against its own set of local data sources. In the future, we are not necessarily syncing against an HTTP server. "Peer" is a better word, because it covers clients and servers. Multiple peers want to synchronize against the same local data. That's where the current configuration system becomes awkward. It forces us to duplicate certain configuration settings (local data sources, logging). When looking for local database dumps for restore, it would be necessary to check multiple configurations. Therefore I suggest that we change our configuration layout. Instead of a "server configuration" directory, we start with a "host configuration" (better names welcome!). A host configuration has global settings pertaining to all syncs done with that configuration (logging). It has a set of local source configs (backend and database selection). Then it has a set of peers using this particular host configuration. Each peer has its own peer-specific settings (credentials, URL and transport) and source-specific settings (URI, sync mode). It might even have more than one way of contacting it (Bluetooth, USB), although how to handle this is a bit uncertain right now. My intention is to deal with this inside the per-server config file instead of creating more config files. Because there hardly ever is a need to have more than one host configuration, we could create one named "default" and use that unless specified otherwise. The layout would look like this: .config/syncevolution/ default/ config.ini host config .synthesis shared (!) Synthesis binfiles sources/ addressbook|calendar|.../ config.ini local source config peers/ scheduleworld/ config.ini peer configuration sources/ addressbook/ config.ini peer-specific source config .other.ini per peer and per source storage for backend For each config.ini there's also an .internal.ini which is not exposed via command line or D-Bus API. The exact location of each property needs to be defined. The advantage of this layout is that when a SyncML server contacts us via OBEX, we can select the "default" host config, check whether the server is known already, otherwise create a new peer config using the "default" set of local data sources. In the current scheme it is unclear where the host configuration is supposed to come from. In the new scheme the Synthesis binfiles are shared between peers, as intended by Synthesis. This is not necessary for us at the moment, but some of the binfile features (simplified change tracking via a single "updated" flag in the local database) might be useful for other backends. The drawback of this revised config layout is the increased complexity. Instead of two sets of properties as in the current config (sync properties and source properties) users of the command line and the D-Bus API would have to deal with four sets, even in the simple use case of a single peer. Here's an idea how this could be avoided: when selecting a configuration for a server, create a "view" on the more complex configuration layout which looks exactly like it did so far. The "sync properties" include the ones that are identical for all peers and the peer specific ones. Likewise for each source. Setting the properties puts the properties into the right config.ini automatically. The D-Bus API as discussed so far and the command line interface don't have to be changed. Configs are selected via the peer name, which is typically unique. If not, then appending a @<host config name> makes it unique and can be used to create new host configs. The empty string as peer name selects only the host configuration, which is useful for local operations (restore, status) or accessing all sync reports. In that scheme it may be a bit unexpected that, for example, updating the logdir setting of the "scheduleworld" server affects the config of the "funambol" server. When using the SetConfig(update=false) D-Bus API to remove a config, clients must not remove the host's source properties, because they might still be needed by other peers. I think this is acceptable, considering the advantages of the otherwise simpler API. When asking for a peer template, that template should already be populated with existing host properties, so that it can be written back without unintentionally overwriting those. Speaking of templates, the list of available templates might also contain paired Bluetooth devices which are known to support SyncML. Then (almost) the same UI as for adding an HTTP server could also be used for devices. Another drawback of changing the configuration layout is the question of migrating old configs and changing back and forth between new and old SyncEvolution releases. Ideally migration should be automatic and still allow going back to an older SyncEvolution seamlessly. With two tricks this might be feasible: 1. move existing properties into the new layout and *duplicate* the host properties inside the per-server config.ini 2. recreate the traditional layout with symlinks So we would end up with: .config/syncevolution/scheduleworld/ .synthesis/ -> ~/.config/default/.synthesis config.ini -> .../peers/scheduleworld/config.ini sources/ -> .../peers/scheduleworld/sources/ config.ini files are updated by creating a new file and then renaming it to config.ini. This replaces the config.ini symlink. Also, if a host's source property is changed using an old SyncEvolution, the change won't be noticed by a new SyncEvolution because although the changed config.ini is read, the newer SyncEvolution doesn't take the host properties from there. I think we don't have to support this. The automatic migration also doesn't work if the user has multiple server configs because we cannot "join" different .synthesis binfile dirs. In such a situation the user has to force a migration and be prepared for slow syncs. Without such a forced migration the new SyncEvolution should continue using the old layout. This is easily implemented by using the same config node twice. Finally, the instructions for synchronizing multiple ScheduleWorld calendars have to be updated. When setting up the second scheduleworld config, the name of the "calendar" source is already in use and something else must be used to avoid overwriting the "evolutionsource" property in the existing source. How does this sound so far? -- 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 _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
