On 15 March 2010 11:28, cd34 <[email protected]> wrote: > There are a number of shared hosting companies that are still on > 1.3/2.0 for SetUID. Whether they support mod_wsgi currently is a > question. Whether they will be able to support it in the future might > be an issue.
Since daemon mode of mod_wsgi can't be used on Apache 1.3, it is highly unlikely that they would use mod_wsgi in a shared hosting environment where they are trying to host many users using one Apache instance. This is because embedded mode would see all code running as Apache user in same processes and with no separation. Thus, Apache memory footprint would be excessive and each user could potentially modify another users application. Ie., the same problems as one gets on poor PHP installations. Personally I would suggest that any web hosting company that uses mod_wsgi in embedded mode to support multiple users should be shot. ;-) > I know at one point you and I discussed what it would take to get > broader acceptance of mod_wsgi in hosting environments. As long as > there is a viable path for mod_wsgi support somewhere that supports > 1.3/2.0, you should be ok. Splitting development into a legacy/new > branch would cause some extra work, but, as long as the basic > functionality is there for 1.3/2.0, and security fixes are backported, > I would imagine the workload to be fairly light. > > We do still have a handful of apache 1.3 machines, no apache 2.0 > machines and the rest running apache 2.2. However, the number of > people utilizing mod_wsgi is a pretty small number for us. Yes, still not sure what I am going to do about commodity hosting environments. I have been thinking up good ways of better supporting that type of ecosystem but the problem is that one really wants a system purpose built for that which is actually less featured than current mod_wsgi in some ways, but does add other features as required in shared hosting environments. Any new system also have to encompass ability to host other languages such as PHP, Ruby and Perl. At that point one needs to start talking about something completely new and distinct from mod_wsgi. One could argue that the answer is just to show how existing FASTCGI solutions could be used instead, but frankly I feel that the real answer is a complete reworking of FASTCGI in respect of both the protocol and process management as existing implementations are quite crufty. The aim would be a system which is easy to setup for hosting companies and easy to manage and control through special purpose built web applications which interact with the process management control, which would principally be distinct from Apache. Users themselves would have access to their own web pages for managing their applications, provisioning them, allowing for clean migration to a new application instance when deploying a new version, debugging tools etc etc. The system shouldn't even be linked to Apache and all the important process management stuff would be done in a standalone system such that you could just as easily use special modules/support in lighttpd, nginx and Cherokee to communicate with it. Sure some of these other web servers have means of spawning FASTCGI process but they are specific to those servers. Lets instead look at one system which all web servers could use without limiting the functionality available to the hosting companies or users. It is a lot of work, but since it would potentially be tailored quite a lot to web hosting companies, the number of potential customers/users who would use it would be quite small and one has to question whether it is worth the effort given that return on volunteer efforts like this is going to be practically non existent, especially given that the majority of web hosting companies are stingy. They will quite happily use freely available open source products because it reduces their overheads, but they aren't going to give anything back in return. They also have entrenched infrastructure using FASTCGI and are unlikely to change anyway as that itself would be a cost. Another issue I have had even with mod_wsgi is that you have a lot of trouble getting even existing Python web applications/frameworks to come to the party and make their software easier to deploy to existing WSGI hosting stacks. As an example, some of the Python web frameworks have built in development servers which may it quite easy for people to develop their code. Those development servers do magic stuff to setup the environments. At the same time though, the WSGI interfaces they provide only provide the minimal mapping required and don't duplicate the additional magic environment setup that the development server does. Thus you find problems like Python module search paths not being set up, logging not initialised, special internal application initialisation not being done up front, extra steps required to host at sub URLs of a site etc etc. The end result is that the environment isn't the same and things don't work in separate WSGI hosting mechanisms unless the users go to the pains to work out the extra stuff that needs to be done. Now, they could quite easily improve the situation by providing better means of creating the WSGI application entry point and making stuff properly relocatable, but they don't. Instead what you see is people separately coming up with elaborate buildout recipes to create a WSGI script file which tries to capture all these extra steps for setting up the environment. They are often still incomplete, given they aren't done by the framework developers, and when the framework changes subtly, they can break. If all this was done within the frameworks and maintained by the framework developers, it could make deployment so much easier than the mess it still is now. So, there are various things to be done here, some technically interesting, others not so much. Do you accept that the actual deployment of WSGI applications is still not as simple as it could be and just go and develop yet another hosting mechanisms which is potentially going to have the same issues, or do you try and solve the actual ease of deployment problem? If you do the latter, because not likely to get interest by the framework developers, even though you could come up with a better drop in deployment mechanism, you end up having to create and support individual recipes within that for the major frameworks to cover up the holes as far as the extra steps that are currently forced on to users to do themselves. If you go down that path, then you get stuck wasting all your time on keeping those recipes up to date with respect to the frameworks or having to add more and more as people expect you to support more and more applications and frameworks. With such a thing existing it would also just reinforce with framework providers the sense that it isn't their problem to solve and so unlikely to ever see the frameworks improve their own code. No matter which path you go down it could be a frustrating exercise and so maybe safer to ignore both and just incrementally improve mod_wsgi where possible so at least for what it does it does well even if it means that development on mod_wsgi slows down and stops when run out of things to do. Anyway, that is where I am currently stuck, not knowing what really to do. Ditching Apache 1.3 support was to allow me the option of cleaning up the existing mod_wsgi code to make it easier to maintain and add new features where I can. Based on how that goes then can make a decision as to what to do. My lack of time of time to do things and my current job isn't necessarily helping with my state of mind over what I do either. My actual real job has nothing to do with all this stuff that interests me and is getting to a point where it is a a real chore and not very stimulating. I can't decide what I want to be doing in the limited time I do have to work on my own stuff to keep my mind stimulated and so am starting to just stagnate and wandering whether should just chuck it all in and become a TV watching couch potato instead. :-( Sorry for the long rant, at least I didn't spit the dummy too much over my current frustrations with Python community. :-) 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.
