(Final?) krb5.Conf Lexer/Parser Proposal

[Theodore Ts'o]

On Sat, Jan 07, 2006 at 08:05:15PM -0500, Joseph Calzaretta wrote:
> >and it would only allow the calling application to open one file at 
> >a time, thus removing the inherent ambiguities and traps in the 
> >current implementation.
> 
> That is one way to handle it, although it would (as you mention 
> elsewhere) force the calling application to figure out the 
> implications of combining several files, meaning that a full-featured 
> profile editing tool would need to duplicate much of the work of the 
> profile library (merging the trees, for example).  Another way is to 
> expand the API so that callers specify a file on which to perform 
> each action.  This is not necessarily the right way to do it (gives 
> callers too much power and responsibility) but is at least sufficient 
> to get it done.

I wouldn't you expand the API so the callers specify a file on which
to perform each action; that makes the API much more unweildy (how
*do* you specify which file you want to perform the action; it's OK to
specify non-existing files to profile_init_path, so it can't be
numerically).  In any case, this is exactly the same as restricting
the read/write API to only opening one file at a time, and then
forcing the applicaition to open each file separately --- in either
case, the application is still shouldering the responsibility of
figuring out the impliciation of combining several files.

What you _could_ do is move all of that intelligence into the library
(but at that point I would argue strongly that this should be in
either an entirely separate library, or at least strongly separated
from the read-ony core code) which can figure out the implications of
multiple files, and make the appropriate changes in the first file in
order to get the job done. 

It would probably make things easier in this case to consider adding
the concept of a finalizer not just to a section, but to an individual
relation, and to also extend the profile to support the concept of a
"whitespace" relation, marks a relation as deleted.  Look at the
design of the BSD unionfs.  That way, if a user wants to delete a
specific relation in [libdefaults], it is not necessary to replicate
the entire [libdefaults] section, but just to add a "whitespace
relation" which marks a particular relation as deleted.

That is, if you want to provide a completely general solution to the
problem.  If you don't, there are workarounds, that involve (a)
forcing the library (or the application) to know something about the
semantic meaning of certain sections or relations as to whether or not
they are "single value relations" or "multi-value relations", and (b)
forcing the library (or the application) to know what the default
value is for [libdefaults], so if the user wants to delete it, it the
library (or the application) can simply add a relation to the first
file which sets the relation to the default value.

A further simplification would be one in which you abandon the idea of
a general profile editor, but only edit a few selected relations and
sections which are known to have significance to the Kerberos library.
This would also assume that the application has detailed knowledge of
how the Kerberos library uses various relations, so it can know that
[libdefaults] is always single-value defaults (as far as I know), and
that in the [realms] section, each subsection is a specific realm, and
then it can always replicate and finalize each realm when a user wants
to modify it.

But, note that as soon as you assume that the GUI application has
detailed knowledged of certain semantics of various profiles and
relations, you also lose one of the big advantages of the profile
library, which is its flexibility and extensibility.  One of the
design goals of the profile was to make it trivially easy to add a new
tuning knob to an application or library.  Once you posit that the
only way of modifying a particular config libary is not via a text
editor, but requires a GUI progammer/designer to re-layout a dialog or
popup box to add a dropdown box or radio button set, then you've lost
much of the value of this flexibility.  

*That's* why I believe it's critically important to have a text-editor
friendly format; it makes it easy to add new configuration parameters.
If the GUI folks end up being working with a restricted feature set
(and heck, GNOME has been chucking out features left and right to the
point that that some power users are abandoning it), then hey, maybe
GUI-only users only want/need/deserve a poor, restricted set of
features.  But I want something at least for applications that I'm
involved in which power users do have the capability of making
fine-tuned adjustments.

(And if the concern is that users who think they are power users but
who are really idiot makes changes and thus make life a support
nightmare, is there a way in Windows or the Mac to set some magic file
type which prohibits most text editors from touching the file, unless
someone manually changes the file type back to "text"?  Or maybe there
should be an option to encrypt the config file with a known key, and
not give out the config file to normal users, to force them to use the
GUI tool unless they can read the sources and get the key ---- just
joking....)

							- Ted