[ http://issues.apache.org/jira/brows...237
5199 ]

Graham Dumpleton commented on MODPYTHON-165:
--------------------------------------------

Having mod_python directly know about other modules, such as mod_dav, means 
that there then exists a dependency on the other modules. This means that th
e core mod_python developers would need to be knowledgeable about all the ot
her modules and it would in
crease the size of the code base dramatically. This would be a highly imprac
tical situation as it would delay development and new releases of mod_python
 because any problem with support for one third party module would delay any
 release of mod_python as a
whole. By exposing the internals and having something like mod_dav_python be
 separate, it can live its own life with the mod_python developers not needi
ng to worry what happens with it. If mod_dav_python were never completed or 
people lost interest in it
, it would not matter as no effort has been wasted on it by core developers 
and its aborted development wouldn't have impacted on mod_p
ython core.

The mod_python core is quite simple at this stage, lets leave it this way ra
ther than turning it in some bit of bloat ware of which the majority only us
e a small bit. :-)

> Exporting functions from mod_python to allow access to interpreters etc.
> ------------------------------------------------------------------------
>
>          Key: MODPYTHON-165
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-165
>      Project: mod_python
>         Type: New Feature

>   Components: core
>     Reporter: Graham Dumpleton

>
> I have ranted a bit about this before:
>   http://www.mail-archive.com/python-...g/msg01087.html
> and issue came up again recently on httpd mailing list so thought it was t
ime to note my ideas about it.
> The idea is that mod_python should export a number of functions using:
>   APR_DECLARE_OPTIONAL_FN
> macro so that they are available to other Apache modules.
> These functions would allow access to interpreter instances, the stored Python req
uest object for the current request, as well as functions for creating server, filte
r and connection Python wrapper objects. The functions and prototypes would be somet
hin
g like the following:
>   PyInterpreterState *mp_acquire_interpreter(const char *name);
>     Get/create the Python interpreter instance called "name". A thread sta
te
>     object would be created as necessary.
>   void mp_release_interpreter(void);
>     Release the currently held thread state object for the interpreter.
>   PyObject *mp_get_request_object(request_rec *req);
>     Get the Python request object wrapper for "req". A new reference is re
turned
>     which will need to Py_DECREF'd when no longer required. If the request
 object
>     instance had already been created within mod_python or through an earl
ier call,
>     it is a reference to the existing instance that is returned.
>   PyObject *mp_create_server_object(server_rec *server);
>     Create a new instance of Python server object wrapper for "server". Th
is is a
>     new reference and will need to be Py_DECREF'd when no longer required.
>   PyObject* mp_create_connection_object(conn_rec *connection);
>     Create a new instance of Python connection object wrapper for "connect
ion".
>     This is a new reference and will need to be Py_DECREF'd when no longer
 required.
>   PyObject* mp_create_filter_object(ap_filter_t *f, apr_bucket_brigade *bb
, int is_input,
>                               ap_input_mode_t mode, apr_size_t readbytes);
>     Create a new instance of Python filter object wrapper for filter and b
ucket brigade.
>     This is a new reference and will need to be Py_DECREF'd when no longer
 required.
> It is actually quite simple to create these wrappers around current mod_python int
ernals. What it would effectively allow you to do is to create an Apache module whic
h is written principally in C code and which therefore has access to all features of
 Ap
ache. Ie., it could define its own directives or even access stuff like mod_
dav hooking mechanism. Having used all those mechanisms to set it self up, w
hen it executes it could acquire a Python interpreter instance and make call
s out to Python code to per
form work. The Python wrapped request/server/connection/filter objects can be supplied to th
e Python code, as well as any other Python objects the module itself creates which wrap up o
ther parts of Apache, for example, mod_dav structures.
> The only part of the current mod_python that needs to be changed to support this i
s that how the interpreter name is stored in the Python request object needs to be c
hanged, specifically it has to be removed. This doesn't mean req.interpreter will no
t w
ork, when that is accessed it would behind the scenes link back to apache.in
terpreter for the name of the interpreter the code is executing under and ge
t it from there.

[ Post a follow-up to this message ]