[ https://issues.apache.org/jira/browse/MODPYTHON-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Graham Dumpleton closed MODPYTHON-165. -------------------------------------- > Exporting functions from mod_python to allow access to interpreters etc. > ------------------------------------------------------------------------ > > Key: MODPYTHON-165 > URL: https://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://email@example.com/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. - You can reply to this email to add a comment to the issue online.