Proposed lexer for parsing krb5.conf files
wyllys.ingersoll at sun.com
Tue Nov 22 15:22:08 EST 2005
Theodore Ts'o wrote:
> Speaking as the person who originally came up with the profile
> format, the design goals were:
> *) Easy to read and understand how to use (because getting help
> writing documentation has always been hard)
No question, XML sucks from a readability standpoint.
> *) Easy to extend when we need new configuration parameters (yes, XML
> can do that too).
Yeah, I think the extensibility argument is a wash, either one can
> 2) Many XML libraries are complete and utter bloatware:
> % ls -l /usr/lib/libxml2.so.2.6.22 1080 -rw-r--r-- 1 root root
> 1100496 Nov 2 13:39 /usr/lib/libxml2.so.2.6.22
> compare and contrast that to the profile library implementation which
> I already did; it's smaller by some two orders of magnitude...
Sure, but the tradeoff of having to write your own profile parsing
code and just using a complete off-the-shelf implementation has its
advantages. Of course that assumes you are starting from scratch,
which is not the case here. So, while I agree that that is a
rather large library, size alone is not a very compelling argument against
it's use, especially in today's computing environments, a 1MB shared
object library isn't terribly unusual or "bad" just because it is
> Many people already understood the windows-style profile
> configuration file; it is intuitively obvious what it means, and can
> be easily edited using a text editor. XML is much more difficult....
Again, agreed. XML sucks for readability.
> > Nothing says you cannot maintain backwards compatibility with the
> > old format. As I said, some simple pre-processing of the config
> > file would easily reveal the format and tell the code how to
> > proceed - use XML or use the old format.
> Bad idea, not with the same filename, at least. What happens to old
> krb5 libraries or old applications statically linked with old krb5
> libraries that don't understand XML?
Noone would be forcing a new format on anyone. If there are legacy
apps that cannot upgrade for whatever reason, then that user would
have to stay with the old format.
> If you want to choose the a different name, say /etc/krb5.xml, and
> then you don't mind linking with some large, bloated XML library, be
> my guest. Of course, some people who have to live with
> applications/libraries using both config files would probably
> appreciate code that can synchronize the two config files --- at
> which point one really has to ask the question about whether there
> are enough benefits with XML that in this specific case, it is
> worthwhile to use the politically correct data format. Or whether
> this is more about religion than anything else.
The approach of having it in a separate file and then synchronizing
to the standard file is attractive in some ways.
I'm not sure of all the benefits, I was just thinking about the
possibilities. I don't even have anything specific in mind
other than possibly having a web-based interface for managing
the configuration. Nothing precludes you from doing this today
using the existing format, of course, but there are cases where
having it in a format like XML, with a DTD to verify the
syntax, would be helpful and might speed development of
More information about the krbdev