Graham, As you know I have been working on/with the MP2MWSGI adapter for a while now since I did not like to do a rewrite of a very extensive code-base where the mod_python Request object is passed around all over the place.
I use the MP2MWSGI adapter in a production environment for a long time now and although it lacks some features of MP since I do not use them and nobody ever got MP2MWSGI from the download server over at bitbucket. It is (as you might remember, but this info is for others reading this) basically a "middleware" between mod_wsgi and a "old" mod_python application. On my production environment I just removed mod_python from the apache config, installed mod_wsgi and with very little configuration my application was up and running again. I even dit some tests on other "WSGI" capable webservers and the MP application performed nicely.... It could very well increase the user-base of mod_wsgi since there seems a lot of mod_python users feeling the pain of rewriting code to move out of mod_python. At the moment I do not see the use of adding the missing features (PSP, authentication; I have that in my own app with my own Session management) but would do so If MP2MWSGI might be added as a new mod_wsgi "sub-project" which I will support and then there is a need for adding the missing stuff so I will do that, it is not that much work anyway. wat it will do is remove the need for "external" middleware and will add all the good stuff of MP (Request Object, Session management, Util (FieldStorage), etc.) Since I have a lot of other goodies added to my system to support things like AJAX stuff, the use of SQLAlchemy (Database independent Object mapper) for sessions, user-management etc) ExtJS, WebDav with database storage, Javascripts in the Database (editable over Webdav) etc. etc. they might be added too depending on user request. The list of additions is very long since I have been working on it from the very beginning of mod_python. I know It can add "features" to mod_wsgi on a different level than that you asked for but seeing your question I wanted to bring my stuff to your attention again as they become "almost free" to you in the time perspective. Others Interested in this, drop me a "personal" email when you think your discussion is "not in place" on this list. Martijn On Jan 20, 2011, at 3:47 AM, Graham Dumpleton wrote: > This email is an official call for feedback from you as a mod_wsgi > user as to what new features you would like to see added to mod_wsgi. > > Part of the reason for the current code cleanup I am doing is to make > it easier to add new features. I have for a long time had my own ideas > for new features but my time to work on mod_wsgi has been quite > limited for the last couple of years. This year though should be a lot > different and expect to be able to do a fair bit of work on mod_wsgi > to enhance and make it more versatile. > > Although I have my own ideas, I rarely hear from people out there > actually using it as to what features they would like to see and which > would make what they do easier. It seems you all just accept what you > are given and don't question it. I am particularly surprised (at least > that I know of), to not really see probing questions from people > setting up these new breed of WSGI hosting services in the style of > Heroku as to the best way they might use mod_wsgi, or to see feedback > from them on what features they would like to see to make it easier. I > know some are actually using gunicorn, but others are still using > Apache/mod_wsgi. > > So, what new features would you like to see in mod_wsgi? > > I'll will describe one major feature just so people don't just ask for > it when already well on the way to working out how to implement it. > > That one feature is the ability to define a template for a daemon > process group with new daemon process groups setup according to that > template being able to be started dynamically without having to > restart Apache. That is, instead of having to change the static > configuration of Apache, could be as simple as just dropping a WSGI > script file in place and when a request occurs which gets routed to > that, a new daemon process group for that application is created > automatically, with it running with user/group corresponding to the > ownership of the WSGI script file. > > Anyway, post your ideas and I'll comment as appropriate, indicating > whether already being considered, not practical, or already > implemented and you didn't know about it. > > Graham > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
