[mod_python] Re: [modwsgi] mod_python publisher

Graham,

Thank you, You gave me the answer I expected....

I need a MOD_PYTHON_WSGI module so I will build one. I do not mind it to go public if it helps.
It will be a pure Python module so people can easily ajust/extend for there own needs...
at first I will create a request object and then I will add stuff like sessions.

Since I never have used the publisher handler (and to be true not even know how it works) I will leave that to others.

I'll keep the mod_python and mod_wsgi groups up to date, but I might bother you with some minor details.
Is it OK for me to re-use MP code?

I think MP programmers like the way they can define their application without a framework, like me the transition to WSGI cannot include a framework that doubles work already done (my system is an implementation on its own framework).
People interested might email me to get their "wishes" and needs.

we'll see

Martijn


On Nov 11, 2009, at 12:29 AM, Graham Dumpleton wrote:

> 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
>> 
>>