Graham Dumpleton
graham.dumpleton at gmail.com
Wed Nov 11 05:15:23 EST 2009
2009/11/11 Martijn Moeling <martijn at xs4us.nu>: > 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? As long as you respect the fact that it is licenced under Apache Licence 2.0 and abide by conditions of that licence you are fine. Graham > 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 >>> >>> > >
|