Graham Dumpleton wrote: > 2008/10/15 Clodoaldo Pinto Neto <[EMAIL PROTECTED]>: > >> 2008/10/14 Graham Dumpleton <[EMAIL PROTECTED]>: >> >>> Anyway, if you have followed along with my ramble, can anyone see any >>> reason why mod_wsgi shouldn't ditch the goal of happy coexistence with >>> mod_python? >>> >> Apart from not being able to run legacy applications, no. What to do? >> Use one server for mod_python and another for mod_wsgi? Given today's >> prices that would not be all that expensive if i don't count the >> doubled server maintenance work time. >> >> Do you plan to break the coexistence in 3.0? 2.x would be maintained >> condescending with mod_python? >> > > Would only do this in mod_wsgi 3.0. Version 2.X would still be > maintained and important/easy fixes backported as necessary. > > The error message that mod_wsgi 3.0 would produce if mod_python also > loaded at same time could even explicitly state to use older 2.X > versions if need support for mod_python at same time. > > Having to use 2.X shouldn't be a problem for people as long as > important fixes made to it, as the WSGI interface doesn't change. All > you loose from using mod_wsgi 3.0 would be new features or > improvements. > > >> What is the risk, if any, of people not >> adopting mod_wsgi because of its incompatibility with mod_python? >> > > The biggest obstacle at present that I can see in respect of people > using mod_wsgi over mod_python is that the Django folks still push > mod_python as the preferred option. That and a few web pages and > people in IRC channels still referring to mod_wsgi as young, immature > and potentially full of bugs. I ask, how many years and how many major > sites are needed before people will accept it is working fine. :-( > > Other major Python web application frameworks openly push WSGI as one > of the options, if not preferred option. Beyond that, any stuff which > is bound to mod_python either has little mindshare so as not to be > worried about, or is a legacy application for which there are most > likely alternatives. > > Of course, this may be fine for people starting on new applications, > who can choose, but obviously a problem for all those old in house > applications that use mod_python. > > >> What would be the cost of a compatibility mode compile option? I imagine it >> would be difficult to maintain two code paths. >> > > If I didn't want to play with the idea of pushing Python > initialisation into child processes, probably not that hard to > maintain support for mod_python. I would though change it so that it > dynamically detected whether mod_python was used and only include > compatibility hacks/wrong behaviour if mod_python being used. Even > with an option to defer Python initialisation to child processes being > optional, albeit disabled when mod_python used, supporting mod_python > still probably isn't that hard, but just would prefer to draw a line > and not have to have the hacks and complicate the code. > > The only other option would be to fix mod_python at same time and say > that if you want mod_python at same time, to use mod_python 3.4 (not > yet available at this stage obviously). Even if mod_python code fixed > in subversion repository, not sure could even muster a release as > don't even have enough active developers on mod_python at the moment > so as to get the required votes to approve it. Would need to drag some > of the prior developers on project management committee out of slumber > to do it. > > Sounds like a good idea but there will be effort required to spread the word - probably need a good post on the Django community blog page - then maybe some patches to their docs.
Also some info to the major hosting services (ie webfaction, linode, slicehost...) with a press release for them to send to customers and docs on how users should install or use mod_wsgi. There will be a surge of questions so best to have faq ready. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
