quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (MODPYTHON-165) Exporting functions from mod_python to allow access to interpreters etc.
Date Mon, 11 Sep 2006 10:10:22 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-165?page=all ]

Graham Dumpleton resolved MODPYTHON-165.
----------------------------------------

    Fix Version/s: 3.3
       Resolution: Fixed

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

> 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
>          Issue Type: New Feature
>          Components: core
>            Reporter: Graham Dumpleton
>         Assigned To: Graham Dumpleton
>             Fix For: 3.3
>
>         Attachments: mptest.tar.gz
>
>
> I have ranted a bit about this before:
>   http://www.mail-archive.com/python-dev@httpd.apache.org/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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message