per directory configuration

["David N. Welton" <da...@apache.org>]

There are some configuration directives, like Dtcl_Script BeforeScript
that one could quite conceivably wish to use on a per-directory
basis.   Currently, this isn't possible, as Dtcl_Script is a
"RSRC_CONF", or, in other words:

 * (req_override & RSRC_CONF)   => *.conf outside <Directory> or <Location>

(according to http_config.h).

Whereas we really want to be using something like:

 * (req_override & OR_OPTIONS)  => *.conf anywhere
 *                                 and .htaccess when AllowOverride Options

However, the problem is that some of the Dtcl_Script options really
are global, such as GlobalInitScript and ChildInitScript - they
shouldn't be set on a per-directory basis!

So, there are a couple of options:

Create new top-level commands for the .htaccess configurable commands.
Has the advantage of going along with Apache's normal way of doing
things - the disadvantage is of course backwards compatibility.

Create and muck around with a merge_config functions.  The advantage
here is that we can fine-tune the commands to accept what we want,
with the downside being that it may be confusing to someone who is not
familiar with the C code what is going on.

Tweak things at the level of 'set_script'.  Advantage: we get
fine-grain control.  Disadvantage: once again, we are
replicating/mucking with something that Apache ought to be controlling
on its own.

Any thoughts on which one people might prefer?  None of them really
jumps out at me as the optimal way of doing things, although the
merge* may be the best of the bunch, at a glance.

-- 
David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/
         Work: http://www.innominate.com/

Re: per directory configuration

["David N. Welton" <da...@apache.org>]

davidw@apache.org (David N. Welton) writes:

> Create and muck around with a merge_config functions.  The advantage
> here is that we can fine-tune the commands to accept what we want,
> with the downside being that it may be confusing to someone who is
> not familiar with the C code what is going on.
 
> Tweak things at the level of 'set_script'.  Advantage: we get
> fine-grain control.  Disadvantage: once again, we are
> replicating/mucking with something that Apache ought to be
> controlling on its own.

I've gone ahead and done a mix of these two.  In some ways it's a bit
messy, but I'm relatively happy with the results.  I've also done some
rewriting of the core functions, to avoid duplication of blocks of
code, and to organize things a bit better.  Things appear stable, but
since I changed some fundamental things, it's possible (probable?;-) I
broke something.

Commit to come later this afternoon...

-- 
David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/
         Work: http://www.innominate.com/

Re: per directory configuration

[Valerio Gionco <va...@most.it>]

"David N. Welton" wrote:

> [...]

>
> Create new top-level commands for the .htaccess configurable commands.
> Has the advantage of going along with Apache's normal way of doing
> things - the disadvantage is of course backwards compatibility.

Backward compatibility is not so much an issue, as long as you don't need
to change code in scripts. When I install a new version of a package, I
can always expect some change in configuration methods.

> Create and muck around with a merge_config functions.  The advantage
> here is that we can fine-tune the commands to accept what we want,
> with the downside being that it may be confusing to someone who is not
> familiar with the C code what is going on.

Too complex, IMHO.

> Tweak things at the level of 'set_script'.  Advantage: we get
> fine-grain control.  Disadvantage: once again, we are
> replicating/mucking with something that Apache ought to be controlling
> on its own.

I agree.

> Any thoughts on which one people might prefer?  None of them really
> jumps out at me as the optimal way of doing things, although the
> merge* may be the best of the bunch, at a glance.

I'd prefer the first option, but since for my applications I don't need
things like GlobalInitScript and ChildInitScript other possibilities are
equally good.



--
Valerio Gionco   [valerio@most.it]
MOST s.r.l.      Via Bezzecca, 9 - 10131 Torino
************************************************************************
            "Life's not fair, but the root password helps."