Make LottaNZB's configuration mechanism future-proof

Registered by Severin H

The current configuration mechanism has some major disadvantages and limitations: XML is not the most human-readible data format in the world and adds another dependency to LottaNZB so that we stay Python 2.4-compatible.

Our self-baked LottaPrefs class doesn't support sections, a requirement I consider essential for any upcoming LottaNZB feature like plugins etc. We really don't want to have 100 key/value pairs stored in one single namespace, this would be a hard to manage mess.

That's why I suggest to chose an existing, mature (and of course as simple as possible) configuration system that produces INI-style files and automatically convert an existing lottanzb.xml file to the new format.

The new configuration file should look similar to this:

# LottaNZB configuration file

abc: 23434
def: sdfdsf
revision: 2

start_minimized: True


enabled: True
otheroption: sdfdf, sdfdf

enabled: False


This whole blueprint was inspired by the Python application Exaile. Exaile uses similar configuration files and also has a mechanism to update an obsolete file.

Configuration systems that should be suitable:

Python's built-in *ConfigParser*. Not so powerful, but used by countless Python applications. Doesn't support sub-sections (which shouldn't be a problem: [plugins.aplugin]). Example: Exaile. No additional dependency.

*ConfObj* [1] A very mature and powerful piece of software used by some well-known projects like Bazaar itself. Compatible to ConfigParser. BSD license. Still actively maintained project. Meant to be shipped directly with the software that uses it. It weights about 80 KB. It supports Unicode, nested sections, lists etc and has a powerful validation system (sweet!).

*config* [2] Not sure about this. Seems to be well-tested, well-documented and powerful. Uses its own syntax (more JSON'ish). Not GPL'd or similar. More lightweight than ConfigObj though.

I also had GConf in mind for an instance, but this doesn't seem to be a real option since it would make it even harder to get LottaNZB working on non-GNOME platforms.

Seems like we should discuss and plan this blueprint carefully, as we shouldn't make another ground-breaking change in the future.


Blueprint information

Severin H
Needs approval
Severin H
Series goal:
Accepted for 0.4
Milestone target:
milestone icon 0.4
Started by
Severin H
Completed by
Severin H



Lantash 25-07-2008: I don't intend to target this blueprint to LottaNZB 0.4, I just suggest to start working on it in a branch and merge it once it's fully functioning and well-tested.

Lantash 27-07-2008: After trying out about three different approaches, I seem to have found a quite satisfying solution. Its advantages: No additional dependencies or external modules, it only depends on gobject and Python's ConfigParser. Support for nested sections: [plugins.notifications] for example. The config module itself doesn't know anything about the actual content of configuration files. Default values and validation routines are implemented where the configurations are actually used and belong to, e. g. in lottanzb/ (window_height etc.) or plugins/ (...) By sticking to gobject we have all its power at our fingertips: We can observe config values for changes for example. But this doesn't mean we've got to make use of it.


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.


No subscribers.