|
Martijn Moeling
martijn at xs4us.nu
Fri Nov 27 16:25:22 EST 2009
For my personal use I am looking for programmatic compatibility (only), simply to run existing code without MP and on top of WSGI. Sole reason: end of development MP Since I do not use all of the functionality of MP I do not need but am willing to extend MODPYTHON_WSGI to help others. Basically most of the MP users relying on passing the Request Object around would be happy with my work pretty soon. For full code compatibility I have set up a web server on linux with python 2.6.[don't remember] and mod_wsgi. For testing purposes I have simply created a "mod_python" directory in the side-packages. In there are the __init__.py, Cookie.py util.py and apache.py (Session.py is something special in my case). In these modules I have commented out all references to _apache to see what happens. next I have made an index.wsgi There I have "made" the definition of the Request, Connection and Server objects, these might be moved somewhere else (apache.py might be the place). my original module containing the handlers is imported like: import index as app and: app.handler(Request(environ)) does the job (without any change to my application, no upload with body possible yet). The register_cleanup is handled like the example in the wiki of mod_wsgi. For now I keep the references and data in an Array. So for now I have a working mod_python application running on mod_wsgi. ToDo shortlist: Make req.read() (and similair functions) work Solve headers_in. Without that CalDav, WebDav are surely broken (No solution yet, headers_out is done) implement request members (Like Req.parsed_uri) review util and make things like fieldstorage work implement some _apache functionality (log error being the most important for now) change Session.py (Random generator is hooked to _apache functionality, workaround works for now) > > A few questions. > > If you don't use publisher, what parts do you use? > > 1. PSP? No.... I hope I can fix _psp easily..... > 2. cgihandler? No, Will make that work if really needed and possible > 3. FieldStorage? Not anymore (My current production version does, will not be ran on MOD_WSGI ) > 4. Session? YES! but I heavily modified the original Session.py, remember my modifications to store in MySQL? Now I rely on SQLAlchemy > 5. Cookie? See Session, although I am planning to implement Cookieless sessions, somehow, someday > 6. import_module() and import overlay? Not yet, and not sure I will. This I something I would like to talk to you about for best practice in my highly complex situation, currently way out of topic to discuss here.... > 7. request_rec, server_rec, conn_rec wrappers? Do not really understand the "wrapper" part of your question, I think though my story above does answer it, if not tell me.. > 8. ap_internal_redirect() wrappers? Do not use this since my system basically only uses apache and mod_python as a communication layer and a way to use the python language > > Overall, what is it about mod_python that you are doing would make it > a better platform that WSGI? req, req, req and req again. I pass req (the request_req) around, add stuff to it etc etc. My code relies on this so mutch that I need it or rebuild the the entire thing. I am developing a kind of a multi user Operating System with a web based desktop. Tho whole thing is developed so it can be scaleable and I am close to start working on the IDE for application development which will run in the web desktop. I have implemented email, calendaring (CalDAV), fileIO (WebDav), MessageQue (Client to Client, Client to server, Server to Server) etc. etc. So you can even sync your Iphone, Mac, Microsoft Exchange etc. so I need low level stuf... over 5 years of research and development has gone into this. > > Are you aiming for 100% compatibility or more just the style of > writing applications? Must be clear by now > > Some stuff like Cookie and FieldStorage could be switched to more > modern Python standard library equivalents, but obviously they would > not be wholly interface compatible. > I See your point, Interface compatibility is the most important point, If someone wants to pick that up.... > The mod_python interfaces are also quite arbitrary and not well > thought out in places due to egregious growth over time and could do > with some cleanup to make things more uniform. True. I think though that due to the way the mod_python documentation turned out I think programmers messed around until they all got a way to work with mod_python, one found its answer with PSP the other with different handlers. I recognize my need for protocol level programming and the "event" driven handler model. So after using mod_python for a long time I must confess I am still confused about PSP, publisher etc. sorry if I confuse things. > > Graham Martijn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20091127/b1f4bb20/attachment.html
|