Proposed lexer for parsing krb5.conf files

[Wyllys Ingersoll]

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 
handle it.

>
>  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
large.


>  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
new applications.

-Wyllys