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