(Final?) krb5.Conf Lexer/Parser Proposal

[Theodore Ts'o]

On Thu, Jan 05, 2006 at 09:26:49AM -0500, Jeffrey Altman wrote:
> If we want to continue to support chaining of configuration files
> then I think it must be supported.
> 
> The configuration editor in KFW does not generate the "final signifier"
> on sections because there is rarely ever more a single krb5.conf file
> and it would be unclear whether or not the user preferences should be
> treated as an addition to the administrative defaults or an addition
> to them.  Right now there simply isn't a good UI for managing this
> distinction.

It seems likely that the only platform that is likely to want to
support chaining of configuration files is Unix, since it's there that
you might want to have user home directories with user-specific config
files that might override the system config file.  That semantic
concept largely doesn't seem to exist on Windows or Macintosh, even
with MacOS X, probably because they are fundamentally engineered to be
single-user systems.

Part of the problem is that there isn't a particularly a good UI to
show what happens when you do have more than one configuration file
chained together, and we also don't have a good API currently for
modifying the profile tree in anything approaching a sane manner if
there are multiple configuration files.

Of course, this isn't a problem on Unix, where editing text
configuration files is quite normal, and the concept of system default
files and user-specific config files in home directories is a commonly
understood paradigm.

I suspect one of the reasons why the profile library has been getting
harder to maintain (which I suspect might be one of the reasons why
there is a desire to rewrite it) is that it is simultaneously trying
to satisfy the needs of Unix, Windows, and Macintosh systems, both in
terms of system dependencies as well as the user configuration
paradigms and expectations of all of these systems.  As a result, it
was starting to get quite bloated and hard to understand.

One of the reasons why I decided to take a machete to the profile
library was that I wanted to make it be something which was optimized
primarily for configuration needs of Unix applications.  When I did
that, I was able to half the line count (including the test harness
code).  And the core functions actually used by Unix applications
compile down to less than 6k.

So something to consider is whether it is really worth it to have a
single code base which meets the needs of Unix, Windows, Macintosh,
etc.  It may be that it's just not worth it.

I do agree with Jeffery that if you decide to pull out the support for
the final signifier, it's probably worth also simultaneously pulling
support for the configuration file chaining as well.  The result will
be much more anemic configuration file solution for Unix users, but
pulling the final signifier already damages that support quite
significantly anyway, and it will allow you to make the resulting
library much simpler.  Unix applications who want that kind of
functionality can simply use my fork of the profile library :-)

						- Ted