As I've mentioned to Russ in private mail, and on inn-workers a much
longer time ago, I've been working on a config-file parser generator I'm
still calling GUCS (Grand-Unified-Configuration-Syntax), until I come up
with a better name.  It's still incomplete, but I think it's complete
enough to possibly say if or not it's something INN would want to use.

There are a few reasons you probably won't want to use this:
 1) The perl code is ugly.  I've never gotten the hang of writing clean-
looking perl.
 2) The generated code is still generated code.  I believe it's cleaner
than what YACC or Bison would produce for the same function...  But
someone coming into the generated .c file green will probably still have
a pretty difficult time following it.  On top of that, I can't promise
the generator won't be free of bugs...  I believe I can make it pretty
good in that respect.
 3) (probably most serious): It isn't very compatible with our current
config files.  I elected to go a more line-oriented route when I started,
and that still remains.  I also decided that the parsing mechanism needed
some concept of types, rather than the raw-data mechanism we mostly use
now.
group "foo"
{
	stuff
}
group "bar" { stuff }
no longer works.

group "foo" {
	stuff
}
group "bar" stuff
is the syntax I use.  The {} can be fixed to follow INN behaviour,
probably, without all that much trouble.  The strong typing, however,
will stay.  (could mean 'pathhost: foo' is no longer valid, and
'pathhost: "foo"' would be the only way to write that in the inn.conf.)

I also didn't worry too much about configurators needing to know the
structure of the file, separately from INN et al.  Also, efficiency and
memory use were not very big concerns of mine for something so
infrequently used as config parsing...  I only tried to make the both
'acceptable'.

There are two reasons I can think for you to want to use this:
 1) The .g file is not too ugly.
 2) It's process, rather than data, oriented.  I view this as an
advantage, as it means more flexibility in dealing with parsed data.  A
lot of people may disagree, but that's not for me to argue.

I still feel bad about the readers.conf parser...  If you guys decide
to go with GUCS as a solution for this problem domain, I'd like to think 
it's because it's good, in addition to useful.

Please CC: me in all replies, since I'm not on this list.  Thanks,
--aidan
-- 
Aidan Cully       "Umm..  Could you call back?  My house is on fire."
Not Panix Staff      --Tom Waits
aidan@panix.com


-- Binary/unsupported file stripped by Listar --
-- Type: application/x-tar-gz