Re: System administration with GNOME.

On 27 Mar 2000, Havoc Pennington wrote:

> Chris Jones <> 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...

Using SWIG, it's just as easy to bind for most any popular scripting

> 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

Very good idea!

> 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...

Writing a parser in Perl is very simple; especially when compared to C.

> 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.

Enter Gnome-MMC  :)


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