Graham, Would it be possible to detect in code if mod_python has fixed their issues? If so you could do this test in mod_wsgi then continue to load mod_wsgi based on weather or not mod_python became compliant with the newer GIL calls.
-Carl On Tue, Oct 14, 2008 at 11:34 PM, Graham Dumpleton < [EMAIL PROTECTED]> wrote: > > 2008/10/15 MilesTogoe <[EMAIL PROTECTED]>: > > > > 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. > > I think you may be overestimating how many people would be affected, > or at least how many would need both modules. Most cases I have seen > where people have both loaded are people who know no better and just > enabled lots of Apache modules for no reason, or moved to mod_wsgi and > didn't bother disabling mod_python at the same time. In both case they > don't generally use both. > > As for a FAQ entry, there is already stuff in FAQ and documentation > warning about using mod_python and mod_wsgi together and people seem > not to read that based on number of problems one sees on various IRC > channels deriving from them doing just that. > > 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 -~----------~----~----~----~------~----~------~--~---
