(Final?) krb5.Conf Lexer/Parser Proposal

Joseph Calzaretta saltine at MIT.EDU
Sat Jan 7 15:14:30 EST 2006


At 05:52 PM 1/6/2006, Jeffrey Hutzelman wrote:
>I don't know if there are people out there using the capability now, 
>but if there are, removing it is going to cause real problems for them.

I agree.  Is anyone here using it?  Or know of any sites that use it?

>I think "it's slightly easier to parse if we drop it" is not much of 
>a justification for doing so.

Oh, the parsing is easy enough; I don't think anyone's claiming it's 
too hard to deal with an asterisk at the end of a line.*

The complexity issue arises:

1) when you try to decide how to programmatically manipulate the tree 
(adding/moving/deleting nodes) and to flush the information back out 
to the appropriate [chained] configuration file[s], via a reasonably 
simple and consistent API.  Since Ted has moved in the direction of 
eliminating programmatic editing and flushing of the profile 
information, I imagine he wouldn't see this as a problem at all and 
would say that people should just edit the file[s] via their favorite 
text editor.  Those of us who are looking toward an "all-singing, 
all-dancing" profile library, however, might have more of a 
problem.  (Note the word "might")

2) when trying to understand via text editor exactly what's going on 
in multiple large files with finalizers peppered throughout.  A 
particularly full-featured GUI tool could mitigate that complexity by 
explicitly showing which subtrees are overriden by which 
nodes.  (e.g., "Oh, no wonder I'm not seeing any of the kdcs for that 
realm, the whole realms section has been overriden by a near-copy in 
a different configuration file in the chain!  I'll just fix that, 
click, done.")  In either case, it's much easier to understand what's 
going on without the finalizer.  Not that simplicity necessarily 
trumps power, (i.e., "Everything should be as simple as possible, but 
no more so.")  It's just that there's a real tradeoff in this case.

--Joe

Joe Calzaretta
Software Development & Integration Team
MIT Information Services & Technology

*well, I'm not claiming it, anyway.




More information about the krbdev mailing list