[Kolab-devel] Refactoring and enhancing pykolab (and the Kolab Wiki)
paul at boddie.org.uk
Fri Dec 6 01:30:15 CET 2013
I've been taking a further look at pykolab after doing some initial trivial
work on licensing boilerplate  and style-related changes , and I've
managed to make some fairly extensive changes without completely breaking
pykolab, and these have now been added to the following bug:
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
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.
More information about the devel