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. 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.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to