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
