Proposed lexer for parsing krb5.conf files

[Sam Hartman]

>>>>> "Wyllys" == Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:

    Wyllys> Sam Hartman wrote:
    >> >>>>> "Paul" == Paul Moore <paul.moore at centrify.com> writes:
    >> 
    Paul> Why not go crazy and drag krb5 kicking and screaming into
    Paul> Paul>
    >> the 21st century and make the config file XML You get the Paul>
    >> parser, editors, validation, low level API, pretty display,
    >> Paul> base syntax rules, base extension capability all for free
    >> 
    >> Because it would complicate the code significantly and it would
    >> lose us compatibility with existing files.
    >> 
    >> I think the build headaches for dealing with xml toolchains
    >> would be worse than implementing Joe's lexer.

    Wyllys> The profile parsing code could be written to remain
    Wyllys> backwards compatible pretty easily - check the syntax of
    Wyllys> the first few lines and branch the code accordingly.

Yes.

    Wyllys> Switching to XML moves the pain of processing and parsing
    Wyllys> the code out of the krb5 codebase, thus removing that much
    Wyllys> more code from having to be maintained.  

That's incompatible with the above.  If we are backward compatible, we
need to maintain code to do the parsing.

No matter how you slice it XML is more work for us because we cannot
give up the existing format.

Moreover, we currently have a single format used across many (everyone
but Microsoft?) Kerberos implementations for configuration.

So, while supporting multiple backends is not something I'm opposed
to, encouraging proliferation of config formats seems like a bad idea.

Apple and debian (using significantly different approaches) have both
demonstrated that it is fairly easy to maintain krb5.conf in an
automated manner.