Localization is indeed a point. I had never bothered to check whether the default data source name is localized. Hmm, in that case I guess I will add another automatism: when creating a new config, the first data source of each type should be used unless overridden, e.g. with “syncevolution –setup server addressbook=Persönlich”.

@John: thanks for the pointer, I wasn’t aware of this standard. I’m not exactly sure about the use cases, but as we are about to break with the past we might as well do it right. So $XDG_CONFIG_HOME/syncevolution = $HOME/.config/syncevolution it is… I still intend to put the writable properties there, though, and not use $XDG_DATA_HOME for those.

This would mean that you could put your config in $XDG_CONFIG/syncevolution or .config/syncevolution

Just a thought.

Cheers for a great solution by the way. It working great here for sync from phone and Evo next up is my n800.

Another way would be to leave this entirely out of syncevolution and leave this to frontends. Genesis does this for GNOME environments (asking for a server name, a template or a custom server URL (using the funambol template for the other settings), username, password, proxy settings. When selecting the sources to sync, it provides the existing database names for selection. A separate commandline tool could do the same for non-graphical (or non-GNOME) environments.

But if you decide to build this into syncevolution, frontends could use syncevolution directly for the basic setup and still provide further options (like source database selection).

Regarding the file names: Some editors do show the full path to the file, so identical file names would be less a problem. And I like the directory structure better than only organizing them by file name in a common directory.

The other open question is: how many options should be controlled by the user and how many should be taken from the config templates? Okay, let’s think about this a bit: required are account name and password and the template which is to be used. Optionally perhaps a specification of which sources are to be synchronized and the logdir.

Anything going beyond that (servers for which no template exists, non-standard Evolution database names) would have to be configured via an editor. Hmm, this seems doable.

So here’s an updated proposal:

syncevolution –setup [--username name] [--password passwd] server [source1 source2 ...]

This will create (if it does not yet exist) or update (if it exists) a new-style config for server. The default settings for all properties come from an old-style config (if one with the same server name is found), one of the example configs (again, only if one exists) or from built-in defaults. Configs for all sources will be created, but only the ones enabled in the config template will be active or (if sources were listed on the command line) those selected explicitly.

One more comment about the “bad” aspects of the both the old and new config files: the files are always called “config.txt”. If you have multiple of them open in a text editor, then it is not easy to tell them apart. Instead of sources/bar/config.ini and sources/bar/.internal.ini, would it be better to use sources/bar.ini and sources/.internal.bar.ini? Hmm, no, I don’t think so: renaming a source would involve renaming two files, one of them not even visible to the user.

I like your ideas about a new config layout. I especially like the separation of user configuration and syncevolution’s internals.

Regarding Genesis, I would probably simply drop support for the old config style once the new one is supported by a release of syncevolution. If you provide a –migrate option, it would be easy to notify the user and ask for migration, so he or she can continue using Genesis. But this will only become relevant once Genesis has a configuration editor that allows the editing of existing configurations.

You mentioned simplifying the setup. How would you ask the user for the necessary input? With a text interface? Currently, this is what Genesis’ setup assistant does: Ask for the needed information and create the config files in the right place. But of course a text-based interface in syncevolution is more generic and would work on more systems. It’s only a matter of if you want to add this kind of interface to syncevolution itself, or if external frontends should handle this.

If this should take place in syncevolution itself, I might adopt Genesis to access syncevolutions capabilities instead of implementing it by myself. Or I could easily create a python interface for this separate of Genesis, so one could write a text interface using the same mechanisms Genesis currently uses.

Cheers,
Frederik