On Tuesday 02 April 2002 19:48, Andres Kroonmaa wrote:
> because one needs to 1) get some pre-processor (compile it),
> 2) learn it 3) split existing config into templates that comply
> with pre-proc, and then overwrite actual config from templates,
> and when looking for where the hell those final config statements
> originate from, search for latest template versions and compare
> with final config. There is no pointer to originating file in the
> actual config. 4) remember to use the bloody pre-processor to
> regenerate the config, 5) remember to update the templates and
> not the final config. I just don't like it. I want some simple,
> out-of-box ability. I'd intentionally limit myself to only what
> out-of-box functionality provides. To keep it simple.
And is why for the second part of 3, 4 and 5 my proposal of hooking a
pre-processor into Squid is somewhat reasonable, as the running
configuration is then never stored on disk..
squid -f squid.m4 --preprocessor=m4
As for 2, I have already stated my point there. In any case you have
to learn how to use the include facility if you want to make use of
it.
As for the first part of 3, I don't see the relevance. The config
needs to be split what ever method you select, and it is not likely
we can do suitable splits.
As for 1, most people today have at least one suitable pre-processors
already installed.
> If you are veteran coder, you usually don't even think of such
> matters and simply write yet another unparsable selfmodifying
> perl pre-processor script with all the bells, pager notifiers,
> cold beer and all. don't you? ;)
No, that stinks. You write your own scripting language integrated
with your own configuration database for the job, and your own SSL
enabled web server to talk to it, obviously driven by the same
scripting language for HTML GUI generation, and the database full of
triggers to make sure the correct actions is performed whenever there
is a configuration change in the system or problem needing attention.
> The only universal and available preprocessor is between chair
> and keyboard. All else has added trouble.
Perhaps.. also the biggest source of errors.
> Default squid.conf is already over 100K in size. There are over
> 200 tags to handle. At times you just want to split it up, for
> readability, grouping. Pre-processing is surely a solution, but
> throwing it at such simple task is abit extreme.
Actually the squid.conf that people need to consider is not more than
a screenful.. but it is hard to see the forest for all trees..
> includes in config might have some other interesting side-effects
> based on how people get confused with multiple shared configs.
> I'd rather listen up to people if some has any good reason why
> includes are bad idea fundamentally, from human factor
> perspective. Its not very common to support includes in configs I
> guess.
Both yes and no..
Not very many config file formats supports general includes as direct
part of the config file format syntax.
Some do, and most who do have also found that they need to add some
simple scripting capabilities as plain includes is rarely sufficient
for the job when includes is needed to get things organised..
Most who to use a standard pre-processor to do the job. For older
programs this is most often cpp, but as cpp has gotten more tied to
the C language over the years this is becoming less used..
Some have had their configs split "for readability", but then
abandoned this and collapsed everything into one file again as the
"split for readability" was based on assumptions on how people want's
and should configure the beast, and these assumptions then collide
with how other people actually wants to configure things making their
job many times more complex.
Quite many (Squid included) supports data includes, where data can be
read from a file instead of specified manually.
Very few programs distributes a default config file mentioning all
the zillion directives and their use. Most distribute a simplified
template with what most people need to use and comments on how to
make proper use of it, wich the full documentation separately for
those who want/need to read all the gory details.
Regards
Henrik
Received on Tue Apr 02 2002 - 12:58:14 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:56 MST