(Fwd) Re: includes inside squid.conf

On 2 Apr 2002, at 16:03, Henrik Nordstrom <hno@squid-cache.org> wrote:

> On Tuesday 02 April 2002 15:24, Andres Kroonmaa wrote:
>
> > Guys, plz don't sweep from one extreme to another. Basic includes
> > is very simple way to organise common options for many squids. Its
> > so rudimentary that even thinking of some external tools makes me
> > puzzled.
>
> Why? (on first and last sentence, no point arguing about the middle
> one)

 1) extremes are, ... abit extreme. (does that answer your 1st Q?) ;-)
 2) all I want is to include common options to all squids I'm running.
    I want to sync these changes between boxes so that unique settings
    don't get wiped away. I do that occasionally. Its very simple thing.
    I don't like the need to run some pre-proc on every box and needing
    to preinstall it first. Maximum effect with minimal effort.

 When we need much more fancy scripting functionality, I agree, its
 better done outside squid for now.

> > Sure, we can go further and say that it would be simpler to NOT
> > have any config parser at all and precompile all options we'd need,
> > and have some good pre-processor that recompiles squid based on
> > templates. And best-known preprocessor is human, of course.
>
> A bit extreme I would say.. but why not ;-) Naa. Recompiling is a bit
> of too time consuming task, and cannot easily be done "on the fly"
> for non-intrusive reconfiguration.

 Well, we can think of recompiling only globals.o and link, or even
 make it dynamic library..., or use debugger to patch squid binary,
 or even running memory image... and perhaps write some guidelines
 how to do that yourself ;-)

> > Its all about balance between convenience and needless complexity
> > in the end.
>
> It is, and I am now arguing that we do not need to increase the
> complexity of Squid with include support in the parser in order to
> provide this to the users.

 And I don't want to add any complex parsing to squid.
 Simple include is not complex addition. Inode checks seemed
 simple to me, but without them its even more trivial if we limit
 the depth low. Expanding relative paths into absolute seemed to
 me on the complex side of things. But thats only me.

> > Of course there are good tools like m4, but why on earth would
> > one user want to get familiar with it? What about portability?
>
> m4 is considerably more portable than Squid. I don't see the problem
> really..

 Windows too?

> > We junked optional includes, ok. We junked strict config reuse
> > detection, ok, now we are on the verge of junking whole idea of
> > includes as well? Common, being userfriendly can't be that bad.
>
> There is no reason why we can't, and at the same time being user
> friendly.

 Yes, most user friendly way is: "do it as you please, ;-) ".
 We don't have universal pre-processor, so all we can do is to
 give some guidelines how people could implement the feature.

> > OK, how about limiting recursion depth to 1? No issues with loops,
> > included parts can be generated or synced the way whoever likes,
> > but people who dislike fancy preprocessors still can make quick
> > use of includes to organize their configs.
>
> And why not utilize an external pre-processor to do the job?

 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.

 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? ;)

 Good pre-processor could be very nice too, being even backward
 compatible, but I guess that we have more important things on
 todo and it won't mature.

> Note that I am not proposing m4 as THE pre-processor for Squid. Only
> arguing that includes etc should be done by pre-processing of the
> config file.

 The only universal and available preprocessor is between chair
 and keyboard. All else has added trouble.
 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.

 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.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Apr 02 2002 - 10:55:33 MST