On Tue, Nov 18, 2008 at 1:25 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > 2008/11/18 Nimrod A. Abing <[EMAIL PROTECTED]>: >> I understand that the whole idea behind WSGI is to provide frameworks >> with a consistent API and specification to write code against similar >> to what Java Servlet API provides. Therein lies the difference. A .php >> file is either HTML with PHP code embedded, or purely a PHP file. >> Either way you don't have an API or specification to write against. A >> .wsgi file is Python app written against the WSGI spec. With >> mod_python you sort of have that same freedom you have with PHP but >> you still need to concern yourself with the CGI. > > For PHP their may not be a strict entry point like with WSGI, with > instead the script itself effectively being in the inner port of the > application entry point, but you still need to deal with an API of > sorts within it when dealing with response at least. If not, can't set > headers or override response status. > > http://au2.php.net/header > >>> The daemon mode in mod_wsgi is a part solution to this, but as it is >>> now, it requires WSGIDaemonProcess/WSGIProcessGroup for each user to >>> be set up and configured. Although this may not be a big problem if >>> administrator has to create a VirtualHost container for user anyway, >>> it isn't if they use database driven virtual hosting. >>> >>> To cope with this, have already described idea for transient daemon >>> process and wild carding configuration so can be driven from database. >>> This is described in: >>> >>> http://code.google.com/p/modwsgi/issues/detail?id=22 >> >> Nice. Your last comment bothers me though: >> >>> Now not likely to be done in version 3.0. >> >> Does that mean we won't see it backported to the 2.x (or 1.x) line? > > It would never have been back ported anyway. 1.X and 2.X streams only > get bug fixes with the way I treat release numbers. New features only > go in major versions. > > Whether it gets done in version 3.0 comes down to time. Even with my > baby being almost 1 year old, my time to work on mod_wsgi is still > very constrained and one needs a lot of head space to work on > something like the transient daemon process feature. > >> I'm not just talking about simple code embeds like this. I'm talking >> about large programs. Think "Zend Framework" or "Binary Cloud" large. >> The edit-upload-run cycle is what makes PHP so attractive. Even in a >> large framework, you can simply tweak a file/module load the site on >> your browser and see immediate results. >> >> Where you say "an administrator could just as easily set this up >> before hand for users for mod_wsgi" is where the problem lies. As far >> as PHP programmers are concerned, they don't need to concern >> themselves with the how server's set up. I'm talking about virtual >> hosting setups here where you can buy hosting space for $8/month and >> it comes with everything you need to run PHP. They just write their >> code and upload it to a server and it runs. > > Users don't have to concern themselves with the setup only because the > hosting provider made a prior decision to host PHP code and set it up. > If the hosting provider decided that hosting Python was also a good > idea and had similarly done the required setup just like they had for > PHP, then again wouldn't be something that the user would have to > worry about. > > Now we may not have all the building blocks in place just yet, but > there is no reason why a similar positive experience can't be had by > Python developers. Just look at Google App Engine as an example.
Good that you mention Google App Engine because this: http://code.google.com/appengine/docs/gettingstarted/helloworld.html and this: http://code.google.com/appengine/docs/gettingstarted/uploading.html Is what I am talking about. Specifically just being able to upload my app along with configuration file and just expect it to work. Of course you can do much of the same using .htaccess via SetHandler and AddHandler and Location directives but it all really depends on your hosting provider. They might have AllowOverride locked down so that adding and setting handlers don't work. So what it all really boils down to is that there is already such a thing as "web friendly python" and what's really needed are more "python friendly hosting providers". > There > is no reason why one couldn't do something similar with Apache as a > base. If daemon processes are used, if uploads are mediated through a > web application then as a side effect it can touch the WSGI script > file to enact the necessary restart of application. Thus it all comes > down to the solution around the hosting mechanism for managing it and > interacting with it. I was under the impression that all WSGI and mod_wsgi needed was a fancy-pants website filled with marketing buzzwords and new names for old concepts. It worked wonders for Rails and from what I have seen lately, seems to be working for Merb as well :) -- Best Regards, Nimrod A. Abing W http://arsenic.ph/ W http://preownedcar.com/ W http://preownedbike.com/ W http://abing.gotdns.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
