Re: mutex dir?

[Jim Gallacher]

Graham Dumpleton wrote:
Jim Gallacher wrote ..

If the settings are going to be a generic key/value like in
PythonOption, but only for purposes of the mod_python system itself,
maybe it should be called PythonSystemOption. Prefer PythonSystemOption
as "Module" is too confusing to me given you have both Apache modules
and Python modules and a module importer. 

Fair enough. PythonSystemOption is a better. The directive definition is
such that it cannot be used in VirtualHost, Directory, Location and so
on which should help emphasize that it's use in only for configuring
mod_python.so initialization.


Also wary of "Config" because
of confusion with "req.get_config()".

Except that PythonSystemOption just stuffs strings into
server->module_config->directives table, which can be accessed via
req.server.get_config(). I can't see any reason application code will
ever need the settings PythonSystemOption might set, so it's not a big
deal if it's not obvious from the name that the settings can be
retrieved with get_config. I like the new name as it signals our 
intention of how PythonSystemOption should be used. This name is also 
consistent with PythonOption, which is a good idea.


I have a better option (pun intended). :-)

We do not need a new directive. Instead use existing "PythonOption"
directive.

That could work.

In the handler code for the directive, it can look at the
value of the "cmd_parms->path" and determine if it is being used outside
of all VirtualHost, Directory, Location, File directives, ie., at global
scope "path" will be NULL. 

The disadvantage is that every request which triggers the 
directive_PythonOption call would require a number of string 
comparisons. Granted this is done in C, but there is a penalty to be paid.

If it is, then stick it in a table object associated
with the server level config for mod_python. This would then be accessible
as: "req.server.get_options()".

Do you see us adding a new apr_table_t field to the py_config structure 
(define in mod_python.h)? Or would these server options go in either the 
directives or options table?

How does req.server.get_options() differ from req.server.get_config(), 
which already exists? And lest we forget the original intent of this 
discussion, we want this so we can pass runtime configuration 
information during mod_python initialization. Maybe it really is more 
logical to have a new directive rather than overloading the behaviour of 
PythonOption.

Because "PythonOption" as used now at global scope results in options
being seen in "req.get_options()", so that still works, we merge the server
options into the request one before overlaying it with the request specific
options.

In other words "req.get_options()" is just like now, but 
"req.server.get_options()"
becomes the subset of options which were defined at global server scope.

Anything used by mod_python itself would use a namespace prefix of
"mod_python." as discussed before. Eg.

  PythonOption mod_python.mutex_directory

It goes without saying that we would be using the new namespace. :)


We can also make use the server->is_virtual field. This is false when 
init_mutexes is first called. (This statement really doesn't connect 
with the rest of the discussion, but it looks like it could be useful so 
I wanted to share).

Jim