INN config file parsing infrastructure

[Fabien Tassin]

According to Todd Olson:
> 
> >According to Bill Davidsen:
> > > 
> > > The use of the # comment character should be clearly defined.
> >
> >I really would like to discourage usage of non-semantic comments...
> >I agree that such comments are very useful for people that manage their
> >servers by hand but if you want to use a GUI (or Web based admin tools,
> >a conf managers, etc.), comments will not survive between changes.
> >That's the purpose of the 'description' and 'skip' fields in incoming.conf.
> >Unfortunatly, I've never had time to finish the project I've had in mind :(
> 
> Hum ...
> what if the convention were to be that any # style comments
> within a {} group were part of that group and were to be moved with
> that group.  Would that address the need?

not really because you can't write back comments if you have skipped them
in the parser (which is usualy the case in all compilers because comments are
useless during the compilation step and later). So, you need to keep them
and the easiest way to do this is to add them to the syntax, just
like other keywords (ie, create a real token for comments). This is
a big limitation compared to the common '#' that's why I've said that 
it would be nice to discourage usage of # (not to remove it completly, of
course).

hmm.. A viable way to keep # comments as is while being able to write them
back can be to insert a token with an increasing number and keep them in a
catalog. This can also be used for formating if someone think it should be
preserved too.

-- 
Fabien Tassin -+- fta at sofaraway.org