[olug] linux web server management ?

[Christopher Cashell]

At Wed, 18 Dec 02, Unidentified Flying Banana William E. Kempf, said:

[Snip.]

> > Each and every one of them requires a different tool - some of them
> > aren't all that well documented compared to the Apache documentation web
> > site or the Exim specification.  Being a GUI doesn't make the
> > configuration tool any simpler :(
> 
> I don't agree.  A GUI is almost always simpler to use than a flat text
> file.  This is usually due to a psychological factor... programmers view
> config files as an implementation detail, and so don't put the same
> emphasis on making its interface usable as they would a GUI.  But what
> ever the reason, I've rarely run into a GUI config tool that I couldn't
> make use of with out ever consulting the documentation.  I certainly can't
> say the same thing for editing a config file.

This is really too application specific to argue, in my opinion.  I've
seen some applications that had horrible monstosities of a GUI for
configuring the application (A built in tabbed window accessed via
Edit->Preferences, including 23 tabs, in 3 rows, and poor organization
and naming), while I've seen well organized and documented configuration
files that I was able to simply open and start editing, without any
trouble.  I've also seen things set up the opposite way.

The whole argument rests on whether or not the application designer puts
forth some effort into making the application easy to configure, whether
it be via text config files, or via a GUI.  Both ways have their
advantages and disadvantages, and both can be easy or hard to do.

One frequent downside to GUI based configurations, though, is that if
you ever, for any reason, need to edit the configuration by hand, you
are often left facing an impenetrable file that is undocumented,
terribly setup and formatted, and never intended to be touched by man.

One other thing to remember, is that many applications in *nix *do* have
GUI configuration abilities.  Usually it's the GUI applications that do
this.  For example, start up a random Gnome/KDE app, and look for an
options or preferences menu.  You'll usually find one.  However, for
console applications, you don't have a GUI that the application uses to
build a configuration editor, so you're left with manually editing text
files.  That's just kind of the way it is, though.  Your configuration
will usually take place in a similar manner as the application runs.

> > The only way to make everything configurable through the same interface
> > is to throw out anything not written by Microsoft and abandon everything
> > older than Windows 2000.
> 
> Uh huh.  Most of those things you listed above put their configuration
> information in the registry, so I *CAN* use a single tool, regedit, to
> configure them all.  Granted, this would be a horrible way to configure
> things on Windows, as the registry isn't designed for this.  But enforcing
> a certain structure on the general heirarchy, and including meta data
> describing the final configuration options, and you get something that
> *CAN* have a universal configuration tool.

I think you greatly overestimate the use of the Registry for application
configuration here.  *Very* few applications store all of their
configuration information in the Registry.  Do a search for *.ini files
on a Windows machine, sometime.  It's still incredibly common for
applications to include some sort of configuration file that is
application specific.  And that's just the files that use the .ini
naming convention.  Many don't.

In fact, the registry makes it worse, because you often can't tell where
you should be looking to make changes to the configuration.  Is it in
the registry?  If so, which of the many complex part of the registry
might it be in (You are frequently left doing a simple search repeatedly
and praying you'll find what you're looking for), or is it in a separate
application specific config file?

Also, the registry is for application developer use.  It isn't, and
never has been, intended for direct editing by users.  The idea was that
applications could use it to store information.  If you ever need to
edit something directly in the registry, then that's a deficiency in
your application.  Personally, I'd much rather hack on some arcane text
file than try to search through the registry to make tweaks.  Text based
config files tend to be much better documented and easier to understand
than random key/value pairs scattered through a huge file.

> XML and DTDs, for instance, should be able to achieve this.  You'll
> still be much better off with a custom config program (or plugin would
> be better, so we have a single config tool), but at least there's a
> chance of being able to configure something for which the developers
> have failed to give you a custom solution.

I'll be honest. . . I don't see this ever happening.  For the same
reason that many programs, especially large ones, don't rely on the
Windows Registry. . . flexibility.

When I'm writing a program, I want it's configuration file to work as
well as it can for the program.  If I limit it's format to some
externally specified standard, then I may have a horrible time trying to
make it work.

Personally, I think XML is a great format for configuration files.  I
would strongly recommend that people use it.  However, it won't solve
all problems.  If a developer fails to give you a custom solution, or at
least more information, a generic XML editor (which is all you could
rely on) would be unable to give you anything more than a list of
elements, attributes, and values, for which you'd have to try to
understand.  And applications vary way to much to standardize on a
single DTD, so you'd be left with a separate one for each application.

And, lastly, you'll have some programs that will never use it.  Some
people dislike XML.  Some people don't want XML parsing libraries
bloating their application.  Some people don't know how to use XML.
Some people will find that XML is a poor format for the specific
application they're working on.  And some applications are small enough
that using something like XML is overkill.

Though I mention XML only above, essentially all points would apply for
any "single" configuration setup.  I would guess that XML is among the
most general purpose and flexible formats available, but I still
wouldn't call it perfect.

> >> Better yet, with standards established you can present APIs for
> >> accessing configuration information, removing this burden entirely
> >> from individual applications.  In other words, from a developer's
> >> stand point the Win32 Registry API is a god send, even if the
> >> monolothic binary registry file is obviously a mistake that Linux
> >> wouldn't need to repeat to get the benefits of a standard
> >> configuration mechanism.
> >
> > This has been suggested - the KDE and GNOME desktop environments even
> > use it.  And it's a WONDERFUL idea.
> 
> I'm not familiar with any of these APIs, so I can't comment too much.  But
> if it's being done, it's failing because there's no standard behind it (or
> more specifically, they only address KDE or GNOME specific apps).

I disagree.  It's working, to some extent, but it'll never be universal.
But, that's okay.  The Gnome (GConf) idea works great for Gnome
applications.  KDE applications are designed to run in KDE, so they can
use their own way.  The fact that they are different shouldn't hinder
it, as the applications are intended to be run under one or the other.

The problem isn't that there's no standard, it's that not everyone wants
this, and some of them have very legitimate reasons for not wanting it.

> > But it's just that - an idea - until you can get people to actually USE
> > the APIs.
> 
> I truly don't think this should be a problem if you define the APIs etc.
> well enough to be universally (or nearly universally) usable.  I would
> expect developers to rejoice in such an offering (and I *am* a developer).

Many of them would.  But many of them will ignore it, too.  Unless you
come up with a way to *force* all applications to use a single interface
for their configuration files, you'll never get 100% standardization on
that interface.  There will always be many people who simply use custom
text files that they process themselves.

And, as a developer who's used many different formats to store
configuration information[1], I've seen a and tried a lot of different
things.  I've never yet found something that would work for every
application I've worked on, though.  I don't think I ever will, either.

> William E. Kempf

  [1]  An external database with a config API, XML, an internal
       key/value database, a simple text file with key/value pairs, a
       complex text file with a line oriented format, a somewhat
       complex (but flexible) text file with a BINDish format, and a PHP
       file utilizing mostly variables and a little logic.

--
| Christopher
+------------------------------------------------+
| A: No.                                         |
| Q: Should I include quotations after my reply? |
+------------------------------------------------+