The config file handling of SyncEvolution is not particularly user-friendly. The reason is that it is a direct port of the Funambol client configuration mechanism, which was supposed to be manipulated via a GUI, not via a text editor. With 0.7 released, now is a good time to rethink that approach. This post explains how the new configuration mechanism could work and how it could be rolled out – this is your chance to object before it is too late!
Let’s start by looking at what is bad about the current system. For a server called
foo with a data source called
bar it consists of the following files:
.sync4j/evolution/foo/spds/syncml/config.txt– settings per server
.sync4j/evolution/foo/spds/sources/bar/config.txt– settings per source
There are a few things which I don’t like about this layout:
- redundant directories: what the heck does
spdsstand for anyway? Do we really need
- Funambol has long ago changed its name,
- Some of these config.txt files are modified by SyncEvolution during a sync.
- The file suffix does not reflect the file type,
.iniwould have been better. With that suffix syntax highlighting in e.g. Emacs (everyone’s favorite editor, right?) is enabled automatically.
I like the simple, .ini-style config files. It is easy to manipulate the settings with shell tools. It’s just the location of these files and the mixture of read/write and read-only properties in the same file which bothers me. So here’s the proposal for the a directory hierarchy:
.syncevolution/foo– base directory for server
config.ini– constant per-server settings
.internal.ini– read/write server properties – hidden from users because of the leading dot
sources/bar– base directory for source
config.ini– constant per-source settings
.internal.ini– read/write source properties
The biggest problem with this change is the transition from older configs to the new one. Since version 0.1 of SyncEvolution it has never been necessary to change anything manually when going to a new version (but there were recommended changes) and it was always possible to go back to an older version. Never has an update forced a slow sync (which can lead to duplicates).
I still find these aspects important and would like to preserve them when introducing the new schema. So here’s the plan:
- if only an old-style server configuration exists, then SyncEvolution will continue to use it
- a new command line option
--migratewill take the properties from an existing old-style configuration and create the new one
There are some problems with this: the GUIs for SyncEvolution (the Funambol iPhone Plug-in and Frederik’s Genesis) make assumptions about the layout of config files and would have to be adapted.
Automatic Changes to Configuration
I also thought about simplifying the setup procedure, for example by integrating the copying of the example configs into SyncEvolution and making the most common changes based on user input without ever opening a text editor. I decided against it because I fear that this will never be flexible enough and not much easier to use than
mkdir -p ~/.syncevolution; cp -r foo ~/.syncevolution; emacs ~/.syncevolution/foo/config.ini.
[Update 2008-02-10] Because of the ensuing discussion and the problem that the example configs were deleted during installation on Internet Tablets I have changed my mind about that: now I think that some options to setup or update a configuration would be useful. The intention is that front-ends like Genesis can interact with the configuration without ever having to read files directly. Here’s my proposal for the new options:
Prints the names of all configured servers to stdout.
Prints the complete configuration for the selected server
to stdout, including up-to-date comments for all properties. The
format is the normal .ini format with source configurations in
different sections introduced with [<source>] lines.
Modify the configuration files for the selected server. If no such
configuration exists, then a new one is created using one of the
template configurations (see –template option). When creating
a new configuration only the active sources will be set to active
in the new configuration, i.e. “syncevolution -c scheduleworld addressbook”
followed by “syncevolution scheduleworld” will only synchronize the
In SyncEvolution <= 0.7 a different layout of configuration files
was used. Using –configure will automatically migrate to the new
layout and rename the old directory $HOME/.sync4j/evolution/<server>
into $HOME/.sync4j/evolution/<server>.old to prevent accidental use
of the old configuration. WARNING: old SyncEvolution releases cannot
use the new configuration!
Overrides a configuration property in the <server>/config.ini file
for the current synchronization run or permanently when –configure
is used to update the configuration. Can be used multiple times.
Specifying an unused property will trigger an error message.
Same as –sync-option, but applies to the configuration of all active
sources. “–sync <mode>” is a shortcut for “–source-option sync=<mode>”.
–properties|-r <file name>|-
Same as –sync-property and –source-property, but with properties
specified in a file with the same format that –print-config uses.
“-” reads from stdin.
–template|-l <server name>
Can be used to select from one of the built-in default configurations
for known SyncML servers. Defaults to the <server> name, so –template
only has to be specified when creating multiple different configurations
for the same server.
SyncEvolution has configurations for:
scheduleworld = sync.scheduleworld.com
funambol = my.funambol.com
Here are some uses cases for these options:
Migrate a configuration from the <= 0.7 format to the current one:
$ syncevolution –configure scheduleworld
Deactivate all sources:
$ syncevolution –configure –source-property sync=none scheduleworld
Activate address book synchronization again, using the –sync shortcut:
$ syncevolution –configure –sync two-way scheduleworld addressbook
Set up another configuration for scheduleworld under a different name:
$ syncevolution –configure \
–sync-property user=joe \
–sync-property password=foo \
–template scheduleworld \
Edit all configuration properties at once:
$ syncevolution –print-config scheduleworld >config.ini
$ $EDITOR config.ini
$ syncevolution –configure –properties config.ini scheduleworld