On Tue, Nov 18, 2008 at 12:12 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > 2008/11/18 Nimrod A. Abing <[EMAIL PROTECTED]>: >> >> On Mon, Nov 17, 2008 at 10:42 PM, Clodoaldo Pinto Neto >> <[EMAIL PROTECTED]> wrote: >>> >>> 2008/11/17 Graham Dumpleton <[EMAIL PROTECTED]>: >>>> >>>> Hmmmm, someone else who thinks they can do better than what is out >>>> there for Python support in conjunction within Apache. >>>> >>>> http://blog.code-head.com/lets-make-python-web-friendly >>> >>> There is nothing there other than vapor, if that much. One thing he >>> has already demonstrated: he has no clue about CGI and mod_python. >> >> While I agree with you on the cluelessness of that post, I do agree >> with some of the points there. >> >> If I understand his post correctly, he is setting out to bring >> complete and total simplicity to the deployment of Python-based web >> apps. That is, write a Python app. Upload it to server and it runs. No >> frills, no conventions to follow, no standards to adhere to. No >> fiddling around with Apache configuration files. No need for root >> access to the server. >> >> This is why PHP is so popular especially for noobs. The idea that you >> can write a dynamic web-based application without caring about things >> like the CGI standard. There is no need to import any special module >> (import cgi). There is no need to adhere to conventions (def >> application()) to get things to work properly. No need to fiddle >> around with Apache configuration files to get URL-to-app mappings >> (WSGIScriptAlias). > > You still need to configure Apache to have it handle .php files. The > only difference is that hosting providers have done it for you already > and so mere mortals don't have to. > > The amount of configuration needed to get mod_wsgi to handle arbitrary > .wsgi files as applications isn't much different. > > For example, for PHP you need at least something like: > > AddType application/x-httpd-php .php > > For mod_wsgi you need: > > AddHandler wsgi-script .wsgi > Options ExecCGI
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. > That is, you don't need to use WSGIScriptAlias, you can just use > AddHandler applied to a directory just like PHP does. > > Doing this though will result in extension appearing in URL just like > in PHP. This can be eliminated in the case of both PHP and mod_wsgi > using: > > Options MultiViews > MultiviewsMatch Handlers > > An administrator could just as easily set this up before hand for > users for mod_wsgi as they could for PHP, such that there is no need > for a user to have root access to be able to add a WSGIScriptAlias > directive. > > So, at that level of configuration there isn't really much difference. > This isn't the real problem though, the bigger issue is the > persistence of Python web applications. How this contrasts to PHP is > quite well described by Ian Bicking in: > > http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ > > Although the above configuration is simple and could be set up before > hand, as is things would run in main Apache worker processes and > because Python code persists and isn't stripped down after requests, > you need to restart Apache after code changes are made. > > 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? >> He just wants to upload a Python program and go. He wants to be able >> to say print "Hello World" without having something on the server say, >> "No I can't let you do that, Dave.". In mod_wsgi, if you wanted to do >> that you need to set WSGIRestrictStdin off, something you cannot do if >> you don't have root access to the server. > > Setting WSGIRestrictStdin to Off isn't going to help here as that will > just mean output of 'print' goes to Apache error log file. They want > output of 'print' to end up in response. The web.py folks tried this > as have Karrigell people. What they do is simply reassign sys.stdout > to make it go somewhere else. In Karrigell though they do it in a > simplistic way at start of each request. Result of that is that it > can't run in multithreaded server. In web.py they try to use a thread > aware replacement for sys.stdout, possibly relying on threading.local > internally to track which response to send back to. In both cases > though it can screw up because of the third party Python modules whole > like to also use 'print' for outputting debug, which rather than end > up in log, ends up in your response by accident. > > Thus, 'print' is not necessarily a good solution. Even if you did byte > code manipulation to change where 'print' goes by default, such as > done in Werkzeug or Jinja (can't remember which), that only extends to > the top level template file and not to Python modules they may call > which would be unexpected if they always expect 'print' to go to > response. > > BTW, as documented, instead of WSGIRestrictStdin you can just say: > > sys.stdout = sys.stderr > >> Horror of horrors, maybe he wants to be able to have <?py print "Hello >> World" ?>. As far as I know there is nothing out there that lets you >> do it that simple. In mod_python you still need to write a handler and >> pass content to the psp module. > > In mod_python using SSI you can write: > > <!--#python exec=" > print >> filter, "Hello World" > " --> > >> In other words, he wants to turn Python into a preprocessing language >> in the same vein as PHP. If he pulls it off, then good for him. > > Personally I believe a very simple means of embedding Python code in > pages would be useful as well and Python support in SSI part satisfies > that. As you see above though, you still have to redirect to the > 'filter' object. What I wanted to do was do the byte code manipulation > I spoke of so that one could instead just write: > > <!--#python exec=" > print "Hello World" > " --> 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. > I could see being able to do all sorts of optimisations over how it > works now. For example, it compiles the Python code on each request > whereas it could cache the byte code from request to request and purge > code from pages not accessed in a while. > > Anyway, part of the reason why I challenge people when I see such > posts is to really find out how much they know about what else exists > out there. I suspect not many would realise that mod_python has > support for Python code using SSI nor prior efforts to overload > 'print' for collecting response content. You should point him to this discussion then :) I know I learned some new things here. -- 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 -~----------~----~----~----~------~----~------~--~---
