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. > > MilesTogoe wrote: > 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. >
Oh and I meant to add that it would be good to have a msg out to all the user groups - I know the Utah user group has been trying to have a wsgi talk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
