Re: System administration with GNOME.



Chris Jones <chris@black-sun.co.uk> writes: 
> Bringing things back to the system configuration tool, it occured to me that
> rather than using Python, Perl or some other scripting languages, it might
> make sense to write the thing in C and then the existing code for the config
> file parsers from the various daemons can simply be borrowed. Why
> waste

One whole point of Python is that you can easily mix it with C
modules. That's why Python apps aren't as slow as Java apps. ;-)
Perl does it too of course, with a little pain. However I don't think
you can really use the daemon's parsers in most cases...


The #1 complaint about LinuxConf is not that the GUI sucks (even
though it does, the text mode UI is OK and many people use that), the
complaint is that it mangles config files.

There are a couple things that are all but required in order to avoid
this:
 - you need to represent the config file in-memory as a parse tree,
   modify the parse tree, and then write the parse tree (libxml works
   like this). If you slurp into a C structure, then convert back to 
   the file format, there is no way to deal with comments, or with 
   config file options you don't understand. With a parse tree you 
   just leave stuff you don't know about as-is
 - you need to have a really good regression test suite with lots 
   of example config files, and you need to actively use the suite
   to avoid bugs

Also, I would note that there are 57 stupid config tool projects out
there that only have a GUI, or that have a grandiouse architecture,
but don't have these config file parsers. The parsers are the hard,
boring, annoying-to-maintain part. Any project that isn't putting
their focus on getting the parsers written _properly_ is just screwing
around...

Sticking a GUI or web-based frontend or whatever on top of a nice
Python module that knows how to deal with the config files is going to
be trivial. Plus nice modules like that would be independently
useful. So a serious project might as well declare these modules to be
their initial goal, IMO.

Havoc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]