Short description
The problem
Many new users, especially ones not familiar with Python in particular or programming in general, have a hard time editing the configuration. The configuration file contains python source code and therefore must obey the syntax rules of Python. Some of these rules, specifically proper indentation, are difficult to understand initially.
In most cases you need to edit the wiki configuration to make a new MoinMoin wiki useful -- at the very least, you need to set the name of your wiki and the starting page name, but you probably also want to change the navigation bar, default theme and possibly the default access control rules. To do all that, you need to change some existing lines, uncomment other lines and type or paste additional lines from the wiki's help pages. The last operation is especially prone to breaking indentation.
Encoding can be a problem too for non-Eglish users.
The situation is worsened by the fact that the "syntax error" problems are very hard to debug, usually requiring checking the web server logs and running script from the web server's user.
Proposed solution
The proposition is to use a more forgiving and simpler syntax for the configuration file, for example the "ini" syntax recognized by the ConfigParser standard module of Python. This configuration file would be an addition to the current wikiconfig.py file, possibly parsed with a command called from it -- thus, it could be overridden or removed easily by experienced users.
This text file could not define all the possible configuration options -- only the ones that are essential and can be represented in it easily.
Example
[wiki] sitename = Untitled Wiki logo_string = <img src="/moin_static161/common/moinmoin.png" alt="MoinMoin Logo"> page_front_page = FrontPage interwiki_name = UntitledWiki show_hosts = yes show_interwiki = yes theme_default = modern language_default = en [paths] data_dir = ./data/ data_underlay_dir = ./underlay/ url_prefix_static = /moin_static161 [security] # note: the list of names is comma-separated super_user = YourName, Other name acl_enabled = yes acl_before = YourName:read,write,delete,revert,admin password_checker = global_antispam = no [patterns] category = ^Category[A-Z] dict = [a-z]Dict$ form = [a-z]Form$ group = [a-z]Group$ template = [a-z]Template$ [mail] smarthost = from = login = [navigation] # left hand side is ignored front_page = FrontPage recent_changes = RecentChanges find_page = FindPage help_contents = HelpContents [chart] width = 600 height = 300 [limits] # allow max. <count> <action> requests per <dt> secs # action = count/dt all = 30/30 show = 30/60 recall = 5/60 raw = 20/40 AttachFile = 90/60 diff = 30/60 fullsearch = 5/60 edit = 10/120 rss_rc = 1/60 default = 30/60
Other advantages
Once part of the configuration doesn't contain executable code, some of its sections could be allowed to be defined on a page on the wiki itself. This would greatly simplify setting up "wiki hives" -- wiki farms where users can start their own wikis with minimal effort.
Disadvantages
Using a pure text file for moin configuration is very unlikely to happen:
- quite some configuration features rely on python features:
- farmconfig (and similar configuration): class inheritance, module importing
- auth configuration (1.7): module importing, instantiation of a list of auth class instances
- antispam: importing a python class from a module
- html headers/footers: definition of a python function
- surge protection: definition of a python dict
- ...
- a text file does not give those features, it would require a lot of custom parser and post-processing code (and lots of developer time), trying to mimic what we have now - with not much chances for reaching the level of flexibility we have now.
- if you make dumb errors in a text config file, it will also fail
- it would likely be limited to some "simple settings" while other settings would still be in a python code config file, increasing the amount of config files we have, requiring different configuration style for different settings
Discussion
At the time 1.7 is released it is much easier to setup an instance by the moin server command. This should work in any case and does hopefully not depend on some distributors changes to the setup mechanism of wiki instances. May be we should urge them not to make such creative changes. In the case of yesterday it sounds like that one likes to have only one instance was completly ignored by the used distribution.
If one has problems and gets his instance working with the 1.7 moin server command, he has added all wikiconfig option to the commandline already. If he would like to have a script then it should be easy to write these parameters down, For that we can use the normal wikiconfig template and do use something similiar to sed.
An
file has much more relaxed syntax than Python code, and is much morewidely known as a configuration file format. Perhaps you don't find the Python syntax rules difficult do grasp because you are actively coding in that language, but for people unfamiliar with it (this includes both people relatively new and experienced oldtimers) the rules seems completely arbitrary, especially when all they see is a bunch of assignments. Adding command-line options for running sed on the configuration files might seems like a exceptionally flexible and general solution, but I'm afraid it doesn't make anything easier to understand. So of course, you won't make it completely idiot-proof, but you can at least make it closer to the expectations and general standards.
Having actual code, like functions and classes, in your configuration files is at the very least "cutting corners", and possibly even a bug. It may be acceptable in a short run, when a feature is new and the code for reading and validating its configuration is not yet in place. But in the long run, it's a hack to be fixed. The example already shows how it's trivial to define lists and dicts in the ini file. I also fail to see how from Auth import foo is that much incompatible with auth_module = foo. Of course, maintaining a configuration file format requires developer time and is a source of bugs. This is currently offloaded to the users who are forced to do the programming and debugging; not all of them are skillful enough to do it. In the extreme, you could always tell them "here is a framework, write your own wiki" -- this approach warrants the greatest flexibility.
I'm wondering how the html headers/footers require defining a function? I always used them as normal strings, both in configuration and in my themes, and they never exhibited any function-like qualities.
After searching the default wikiconfig.py and multiconfig.py files for settings that would potentially cause problems I'm starting to lean towards moving the whole configuration to an ini file and moving the remaining boilerplate code either to the configuration reader or plugins.
Thank you for your feedback. -- RadomirDopieralski 2008-03-14 12:21:43 }}}
This is completely impossible since many features require being able to import other python modules from within the config, instantiating objects (auth system) and similar.