[Kolab-devel] Refactoring and enhancing pykolab (and the Kolab Wiki)

Hello again,

I've been taking a further look at pykolab after doing some initial trivial 
work on licensing boilerplate [1] and style-related changes [2], and I've 
managed to make some fairly extensive changes without completely breaking 
pykolab, and these have now been added to the following bug:

https://issues.kolab.org/show_bug.cgi?id=2660

Naturally, I managed to break and unbreak things on the way, and the patches 
attached to the above bug mostly keep things unbroken, but it can be difficult 
to ensure this especially when submitting "cleaned up" patches. Nevertheless, 
I've attempted to tidy up the command/component framework underlying the kolab 
and setup-kolab commands.

The apparent need for a few other things arose when doing this work, and so 
I'll list them below; they all concern setup-kolab...

Until now, the command has worked in "do everything" mode by default, which is 
perhaps a little too enthusiastic, and I'd like to think that it would be more 
intuitive if the interface presented the configurable components by default 
(the "help" command) and if it could also show components that need 
configuring (kind of emulating the service command) albeit with some extra 
work described below.

The command complains very quickly about things like directory server 
instances and tells you that /etc/dirsrv and /var/lib/dirsrv must be "clean", 
but it would be nice if it could offer a more concrete remedy or at least 
hinted at the tools - other than rm ;-) - that could be used. (The Debian 
dirsrv init script is also unhelpful and needs repeated "prodding" so that 
slapd actually restarts, and I wonder if we might not try and get this fixed 
in Debian.)

There is also some kind of uncertainty about output and logging. I experienced 
abrupt exits of the command where something might have been logged somewhere, 
but on the console there was no indication of failure. Some consistency here 
would be desirable.

I tried to add some "work detection" to the setup commands so that they can 
tell if they probably don't need to do anything, and this has mostly been done 
in the database-related tasks. I made it possible to override the behaviour to 
reconfigure things if this is really desired. Maybe it would be good to 
perform more in-depth tests of existing things to ensure that they really will 
support Kolab and aren't incomplete in some way.

I noticed that there is a kolab-conf command, but I'm not really clear on what 
it is supposed to do. If it is meant for testing the configuration, perhaps 
the above work could be integrated with it, but maybe someone can explain what 
this command should be doing.

On another matter, I brought up the topic of the wiki on IRC, and it was 
indicated that a new wiki instance might be made for Kolab 3, particularly 
since the current instance mostly concerns previous versions (and is gradually 
accumulating account spam). Although I'm sure the emphasis is generally on 
getting things onto docs.kolab.org as quickly as possible, I think that being 
able to formulate things on a wiki might be useful for people like me who are 
trying to be more familiar with the architecture of the solution, with such 
informal notes and ideas obviously not fitting into the proper documentation.

Anyway, I'd like to think that there is potential for making pykolab and the 
associated tools a bit nicer, so I hope this work is of interest.

Paul

[1] https://issues.kolab.org/show_bug.cgi?id=2552
[2] https://issues.kolab.org/show_bug.cgi?id=2554