(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