Krb5 conf file parser: finalizer finale?

[Joseph Calzaretta]

Hello again!

Okay, regarding the profile configuration file parser: (See 
http://pch.mit.edu/pipermail/krbdev/2006-January/004001.html and 
subsequent messages in the thread for context.)

The MIT Kerberos Team has met and discussed the finalizer feature at 
some length.   After much discussion and arguments for both sides, we 
have decided -not- to include the finalizer feature in the next 
version of the profile library.  Here's why (as I recall):

- The feature is not strictly necessary:
   When users need to override the profile configuration in a way 
that simple merging cannot accomplish, they can change the 
KRB5_CONFIG environment variable and edit their own configuration 
file as needed.  This allows as full control over the profile as one 
could want, and the only sacrifice is modularity.  This is the most 
important reason because it shows that the feature is, at best, a 
convenience.  If KRB5_CONFIG weren't an option, there would be a more 
solid argument for keeping the finalizer: there would be profile 
configurations that users could only achieve by using the 
finalizer.  But that is not the case.

- The feature does not seem to be widely used.
   We haven't yet found anyone who uses it.  It seems the most common 
use of multiple config files is to add new sections (e.g., realms) 
and to override "single-value" relations (e.g., default_realm), and 
these do not require the finalizer.  Of course, once we remove this 
feature, Murphy's Law dictates that millions of heretofore unknown 
finalizer users will come swarming out of their hiding places.  We 
can tell these people to change their KRB5_CONFIG environment variable.

- The feature as implemented uses a nonintuitive syntax:
   An asterisk is not a particularly good indicator of 
finality.  Changing the syntax for the same feature (e.g., using an 
exclamation point or the word "final") could fix this, but introduces 
logistical headaches.  (e.g., how do you deal with existing files 
that use the old syntax, or use the new syntax unexpectedly?)

- The feature is not as fully implemented as it should be to be more 
generically useful:
   It does not allow individual relations to be overridden.  Nor does 
it allow relations, sections, or subsections to be deleted.  Thus 
even with this feature, modularity is somewhat sacrificed, and 
changing KRB5_CONFIG may not be a particularly worse 
option.  Expanding the feature by allowing "foo=bar*" and "foo=*" or 
"foo*" would improve the situation, but again introduces logistical 
headaches with backwards compatibility.

- Any implementation of such a feature makes it quite difficult to 
build an effective GUI tool which both programmatically edits 
multiple config files and portrays the results of the merged tree 
structure to the user:
   In showing the tree to the user, how do you indicate a 
value/section is finalized?  Do you also show the overridden vales 
and indicate which file they're in?  If you delete a value or section 
from a file where it doesn't exist, do you delete to white-out or to 
transparency?  If you always delete to white-out, you run the risk of 
slowly duplicating one of the files and giving up on modularity.  If 
you delete to transparency, you end up surprising the user when 
relations or even whole sections "appear out of nowhere".  True, 
logistical headaches show up even without the finalizer, but not as 
many and not as intense.


So, for those reasons, we're not going to implement the 
finalizer.  This does not preclude us from reintroducing the 
finalizer or some similar functionality in a future version of the 
library, if users demand it or the situation changes in some other 
way.  Also, please keep in mind that there are other 
non-finalizer-related parts of the new parser (see 
http://pch.mit.edu/pipermail/krbdev/2006-January/003998.html ) which 
you may not have reviewed.  If you have any comments, questions, or 
concerns, please let us know.  Thanks!


Yours,

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