[mod_python] Thread safety

On 08/06/2005, at 12:43 AM, mike bayer wrote:

> Graham Dumpleton said:
>>
>> Just curious, but what is it about your publisher that is different 
>> to the
>> standard mod_python.publisher or other extensions such as mpservlets
>> and Vampire.
>>
>
> are any of those publishers framework-agnostic (i.e. work in other
> containers besides mod_python) ?   theres a great advantage to being 
> able
> to move an application over to other web environments, such as 
> standalone
> servers, lighttpd etc. either for performance testing or development.
> particularly if they can expose themselves via WSGI, which might become
> the standard interface for delivering Python web applications.

Neither of those two is framework agnostic. They are written 
specifically
to work with mod_python.

Personally I have a lot of doubts about this whole "framework agnostic"
goal as being pushed by WSGI. Although mod_python in itself is quite
simple, in conjunction with the underlying features of Apache it has
huge potential and certainly provides a great deal more flexibility
and configurability than other systems out there. The problem is that
most people don't appreciate what it could do and instead just scratch
the surface.

To me, WSGI in part seems to be solving the wrong problem. The main
problem they seem to be solving is that of there being too many HTTP
server frameworks for Python. At the moment at least, it isn't really
addressing the issue of making higher frameworks any better. In some
respects it can't even truly solve that, as in order to work on as many
HTTP server frameworks as it can, it can only really support the lowest
common denominator. If it started to depend on features that only
certain HTTP server frameworks can provide, then anything that relied
on those exposed features wouldn't be able to be portable, thus making
the whole exercise pointless.

So WSGI is currently great for simple frameworks where you want that 
good
feeling of knowing that it will work on lots of HTTP server frameworks,
but in practice I would argue that if you want to be able to build a
really powerful system you are better of sticking with one underlying
HTTP server framework and using as much power as it gives, rather than
limiting yourself.

Over time WSGI may grow to encompass higher level features that make
it more useful in itself, but at that point, it will just become yet
another high level framework to choose from.

End of rant..... :-)

Graham