Make LottaNZB's configuration mechanism future-proof
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
[general]
abc: 23434
def: sdfdsf
revision: 2
[ui]
start_minimized: True
...
[...]
...
[plugins.floamtv]
enabled: True
otheroption: sdfdf, sdfdf
[plugins.
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.
[1] http://
[2] http://
[3] http://
Blueprint information
Whiteboard
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.
Work Items
Dependency tree

* Blueprints in grey have been implemented.