Exporting functions from mod_python to allow access to interpreters etc.

• Key: MODPYTHON-165
• Type: New Feature
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Graham Dumpleton
• Reporter: Graham Dumpleton
• Component/s: core
• Fix Version/s: 3.3.1

Description

I have ranted a bit about this before:

  http://www.mail-archive.com/[e-mail]/msg01087.html

and issue came up again recently on httpd mailing list so thought it was time 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 request object for the current request, as well as functions for creating server, filter and connection Python wrapper objects. The functions and prototypes would be something like the following:

  PyInterpreterState *mp_acquire_interpreter(const char *name);
    Get/create the Python interpreter instance called "name". A thread state
    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 returned
    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 earlier 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". This 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 "connection".
    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 bucket 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 internals. What it would effectively allow you to do is to create an Apache module which is written principally in C code and which therefore has access to all features of Apache. 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, when it executes it could acquire a Python interpreter instance and make calls out to Python code to perform work. The Python wrapped request/server/connection/filter objects can be supplied to the Python code, as well as any other Python objects the module itself creates which wrap up other parts of Apache, for example, mod_dav structures.

The only part of the current mod_python that needs to be changed to support this is that how the interpreter name is stored in the Python request object needs to be changed, specifically it has to be removed. This doesn't mean req.interpreter will not work, when that is accessed it would behind the scenes link back to apache.interpreter for the name of the interpreter the code is executing under and get it from there.

Comments

[Damjan Georgievski]

Isn't it better if mod_python would be able to use the other Apache modules (like mod_dav)?

[Graham Dumpleton]

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 the core mod_python developers would need to be knowledgeable about all the other modules and it would increase the size of the code base dramatically. This would be a highly impractical 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 needing 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_python core.

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

[Graham Dumpleton]

Attached "mptest.tar.gz". This provides an example of how these functions can be used in practice.

So far all functions described except for that for creating filter objects has been created and added to subversion trunk. It could be argued that if wanting to build filters one should just use mod_python and so possibly not much sense providing access to such a function. This can be reviewed later as necessary.

Other functions which could be investigated for inclusion are ones for determining interpreter based on target of request, access to PythonOption and PythonConfig tables objects etc.

[Graham Dumpleton]

Third time lucky with code. Wasn't returning status correctly and ensuring that cleanup done properly.

[Graham Dumpleton]

Final go at working example in attachment. The code in mod_python works fine, I just keep mucking up the example. All looks okay now. :-)

[Graham Dumpleton]

Anything else related to this can be done as enhancement later.