[mod_python] Apache/mod_python: Registering a request handler dynamically

2008/12/29 Samuel Abels <newsgroups at debain.org>:
> On Mon, 2008-12-29 at 09:11 +1100, Graham Dumpleton wrote:
>> If they can run CGI scripts already, then they can run a WSGI script.
>> They would not need to make changes to Apache configuration. That
>> example relies on having Python 2.5 for wsgiref, but you could instead
>> package your own simple CGI-WSGI bridge.
>>
>> If they already have mod_wsgi available and Apache is configured to
>> run wsgi-script file type, or they can set AddHandler in .htaccess
>> file (same as CGI case), the same script will run fine with no
>> additional packages needing to be installed.
>>
>> If they already have mod_python available and they can set AddHandler
>> in .htaccess file (same as CGI), you could supply your own
>> mod_python-WSGI bridge.
>>
>> If they already have fastcgi/scgi/ajp available, they just need to
>> have flup installed, which supplies a WSGI bridge for those protocols.
>
> To summarize, all require action on part of the user and only work with
> AllowOverride.

Yes, you can't avoid configuration. Configuration either has to be
done in main Apache configuration, or appropriate rights have to be
available to allow a user to do it themselves in .htaccess file. For
some hosting solutions you also need additional Python packages
installed which provide adapters, unless you are going to bundle them
all with your application.

Going back to your original request to be able to write:

  apache.set_default_handler(myhandler)

This can simply not work as the script file will not be loaded until a
request arrives which maps to that script, which is by then too late
to run that code.

One can provide handlers for various phases of Apache
programmatically, but it requires you to have written at least one
hook function to register it. This requires configuration to even have
that run and the registration is only for that specific request and
cannot be registered for all requests.

>> So, WSGI can already be hosted on top of varying solutions. You seem
>> to suggest you want to ignore that and write your own bridges for all
>> the different hosting mechanisms out there, as well as come up with
>> your own private interface specification for talking to your
>> application.
>>
>> So, all this stuff has been done, but if you want to re-invent a lot
>> of stuff, that is your call.
>
> I am using WSGI as one alternative. The point is in adding fallback
> solutions.

Then you are looking at it the wrong way. You should be targeting WSGI
API exclusively for how your application talks to the web server as it
is more or less now the Python standard for doing this. This way you
don't have to provide the support for the fallbacks as the existing
third party adapters, or built in support in hosting solutions for
WSGI should be used. You will find that all the major Python web
frameworks/applications are heading this way. Ie., ditching all but
WSGI support and relying on separate adapters for WSGI where needed.

Part of the problem as I sort of see it, is it looks like you have
made the decision to write your application against the mod_python
specific APIs and are now stuck because you have to make it work on
other hosting solutions, by creating your own custom adapters and fake
requests objects that look like mod_python request object. If you need
portability and this is what you are doing, then using mod_python
specific APIs was a poor choice to make.

Frankly, no new application code should be targeting mod_python
specific APIs, or using mod_python specific high level handlers. The
only good reason for using mod_python these days is if you need to
write custom handlers for interacting specifically with Apache, but
not for the content handler phase, only for earlier phases of request
handling.

So, long term goal of anyone writing actual content generating Python
web applications should really be to migrate to WSGI API.

Graham