[mod_python] Re: [modwsgi] mod_python publisher

2009/11/11 Martijn Moeling <martijn at xs4us.nu>:
> Graham,
>
> I was searching the list searching for answers about moving away from MP to MWSGI and stumbled upon the below conversation.
> Because of the workings of MP my application is heavily based around passing reference to the Request object.
>
> Also I have modified Session.py from the MP package to store session data in a database behind SQLAlchemy.
> Due to trial and error i found out that connecting to the database on each request with the Database closure in
> a fixup request was the best solution in MP not sure yet about WSGI but I would like a similar scenario (which is in the WSGI wiki examples)
>
> In the random number generation part of Session.py is some MP specific code (I do not seem to understand that part)
>
> I have been thinking of making a WSGI-MP adapter to get rid of the runtime or live troubles of MP being code compatible as base for MP applications.
> so yes I am interested, and I would not mind contributing.

It isn't something I have time for these days. Can't even find time to
get next version of mod_wsgi released and only way I will achieve that
is to rip out some half done stuff I had added related to statistics
generation, deferring it to later or try and do it at Python code
level as an example rather than in C code of mod_wsgi itself.

There have been some people who have mentioned before they were
constructing mod_python request like objects for use in WSGI
applications for porting, but seems they only do it for themselves and
aren't interested in making it public.

BTW, mod_python only compiles on latest Apache 2.X versions by
applying a fix. In Apache 2.3 (2.4), even with that fix it is unlikely
to compile as they have changed quite a bit authorization handler
APIs. So, Apache 2.3 (2.4) may spell the end for mod_python unless
someone does the work in fixing mod_python.

Graham

> Martijn
>
> On Apr 24, 2009, at 8:16 AM, Graham Dumpleton wrote:
>
>> 2009/4/24 Matt Newville <matt.newville at gmail.com>:
>>>
>>> I'm looking to move from mod_python to mod_wsgi, and reading through
>>> the on-line documentation.
>>> 've been fairly happy with mod_python for my own scripts, but do
>>> appreciate that mod_wsgi is a better design and the future. I also
>>> want to update a MoinMoin wiki on the same server to using mod_wsgi,
>>> and am concerned about trying to have both mod_python and mod_wsgi
>>> running on the same server.
>>
>> You can run mod_python and mod_wsgi on the same server, but in that
>> case certain features of mod_wsgi don't work as mod_python takes
>> control of initialising Python.
>>
>>> Currently, I'm using mod_python's publisher handler for mapping url to
>>> python function name and arguments, and for basic authentication.  By
>>> themselves, the mod_python/publisher scripts I have  (ie, the code
>>> with "from mod_python import apache") are fairly small and simple and
>>> mostly manage a connection to larger python modules  for the
>>> application logic.
>>>
>>> It looks like there isn't an immediate replacement for these features
>>> within mod_wsgi, with the rationale given that such functionality is
>>> best handled elsewhere, perhaps in a larger framework.  Is this a
>>> correct reading?
>>
>> It is only intended that mod_wsgi provide the low level gateway to the
>> server itself. This is in contrast to mod_python which provides the
>> low level gateway to the server, but also high level handlers.
>> Personally I think that mod_python did this was wrong, and the high
>> level handlers should have been separate. Problem it now causes is
>> that people don't want to give up mod_python because they are bound to
>> APIs which are part of the mod_python package. If those high level
>> handlers were separate, then there would have been a better chance
>> that they could have been rehosted on alternatives such as WSGI to
>> allow portability and migration away from mod_python.
>>
>>> If so, what is the recommended path for those for
>>> whom the publisher handler was a good fit?  Are there recommended
>>> extensions that provide this functionality, or migration paths for
>>> code currently using mod_python publisher?
>>
>> There was someone on this list who was trying to come up with a
>> package which offered compatibility with mod_python.publisher but such
>> that it could be hosted on WSGI instead. For my mind, although it may
>> aid in migrating away from mod_python, I don't believe that an exactly
>> compatible system is a good idea, as mod_python.publisher has various
>> aspects which I regard as being broken.
>>
>> Although I have resisted before, partly due to lack of time, but also
>> because I had some bigger ideas in mind, I haven't pursued the idea of
>> creating a package which could be a stepping stone to get away from
>> mod_python and onto mod_wsgi instead. Since I am treading water a bit
>> at the moment working out what direction I am going to take with
>> mod_wsgi and whether I branch out and do something to improve fastcgi
>> hosting, maybe I can have a look at this a bit now.
>>
>> As it turns out, most of the work is already done, as my Vampire
>> package for mod_python had a rewritten mod_python.publisher
>> equivalent. This fixes some of the problems in mod_python.publisher
>> and makes it more flexible, but still doesn't fix some of the things I
>> hate most about mod_python.publisher.
>>
>> Anyway, I could take Vampire and repurpose it on top of WSGI and more
>> specifically mod_wsgi. The main thing I am missing to be able to do
>> that is a request object as obviously relied upon that from
>> mod_python. There are a couple of options there. First is to write my
>> own in order to avoid external dependencies, or use webob. There is
>> also Werkzeug, but it is much more than a request object so may be
>> bringing too much baggage.
>>
>> For forms processing, would just fall back on cgi.FieldStorage, which
>> does mean a loss of a few mod_python features, albeit not often used.
>> The only other thing, but which wasn't really a part of
>> mod_python.publisher, is session support. In some sort of first
>> version one could ignore session support though. Another future area
>> to look at might be to bring across PSP support into the package.
>>
>> The question is whether there is sufficient interest. In terms of
>> gauging that, have also cc'd this to mod_python list. If replying
>> please ensure you reply-all to both lists.
>>
>> Do note that I wouldn't aim for compatibility as me being a pedantic
>> ass means I will not allow some of the stuff in mod_python.publisher
>> which I think is wrong. Obviously the request object isn't going to be
>> the same, although maybe one could have a mode where by you use a
>> request object wrapper to make it closer. As for the other stuff, that
>> may or may not affect many people. The particular area I have an issue
>> with in that respect is the really bad way mod_python.publisher deals
>> with trailing slashes. So, porting work would definitely be required.
>>
>> So, is there any interest in a mod_python.publisher like package to
>> act as a easy migration path away from mod_python?
>>
>> Graham
>>
>> _______________________________________________
>> Mod_python mailing list
>> Mod_python at modpython.org
>> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>