[ http://issues.apache.org/jira/browse/MODPYTHON-165?page=all ]
Graham Dumpleton reassigned MODPYTHON-165:
------------------------------------------
Assignee: Graham Dumpleton
> 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
>
> I have ranted a bit about this before:
> http://www.mail-archive.com/[email protected]/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
