[Web-SIG] Pre-PEP: Python Web Container Interface v1.0

[Phillip J. Eby]

At 02:50 PM 12/8/03 +1100, Stuart Bishop wrote:
>Although there will be more applications than containers, I doubt that
>there will be many that actually implement the Web Container Interface -
>sane people will simply subclass StandardWebContainer (to be defined),

I presume you mean StandardWebApp, since the container is the component 
that *invokes* the proposed interface.


>since sane people generally don't want to rewrite header formatting,
>response buffering, cookie decoding/encoding, POST and QUERY_STRING
>decoding, gzip compression, i18n etc.

Right.  But, again, consider the existing fifty or so frameworks that do 
this stuff.  With the interface as specified, those framework authors can 
slap a few lines of code on top of their existing setup, and have instant 
comformance.  But, the framework author -- except in rare cases -- is 
probably *not* going to be able to specify thread compliance on behalf of 
the actual user application.  Thus, they're going to have to also design 
some way for the framework's user to specify the level of threading support 
to be flagged by the application object.  That's an unnecessary burden, 
when the container is already going to have to manage other kinds of 
configuration.

Also, consider this: only a very few containers will support 
threading.  mod_python on Apache 1.3 won't be threaded.  Most FastCGI 
implementations aren't.  CGI definitely isn't.  That pretty much leaves 
half-async webservers written in Python, like those belonging to Zope and 
Twisted.  And, it's not clear to me at this point if they will even *care* 
about this.  Even if they do, the thread pool models used by Twisted and 
Zope are probably different in interesting ways that are completely outside 
the scope of this proposal.

Easy backward compatibility is extremely important to this interface.  If 
users have to change their apps to make this work, it's not going to 
fly.  If, on the other hand, a framework developer puts a wrapper on their 
framework, then the app is portable.  What's not portable is configuration 
of the container.  It's one thing for a user to learn how to configure a 
container to run their existing app, and another thing to make them have to 
change the existing app to support a thread safety indicator.

What's more, I have the nightmare vision of an app needing to specify 
different thread safety levels for different containers, because of the way 
those containers handle different threading levels.  Explicit 
(configuration of the container) is better than implicit (funnelling a 
safety flag up from an app, through a framework to the interface, for the 
container to then interpret according to its own schema).


>>And last, but far from least, the more things there are in the spec, the 
>>more things there are for people to disagree with or have different 
>>interpretations of.  :)
>
>I think it is good to define a bare interface between request brokers
>and applications, and CGI is a good common denominator to work from.

Great.


>The real arguing will be from wanting to have python ship with
>a higher level interface implementing this specification.

You mean on the application side, I presume?  Containers in the standard 
library (or adapters from the existing containers to allow invocation of 
conforming apps) should be non-controversial.


>I'm
>sure cookies, response headers, streaming & buffering, QUERY_STRING
>and POST decoding can all be agreed on without bloodshed, but getting
>people to agree that standalone Zope Page Templates should go in too
>might be more difficult :-)

I'd assume that a trivial "CGIApp" class would be written so as to simply 
create a cgi.FieldStorage, and invoke an abstract method.  Anything more 
than that would be encroaching on highly disputed and disputable 
territory.  :)  (And perhaps not really needed, anyway.)

But I care almost nothing about the stdlib effects of this proposal for the 
moment.  Anything that happens, won't happen until 2.4.  But, if this 
becomes the "community standard" interface *now*, then framework developers 
can start splitting their container code from their framework code, and 
expand the reach of both their containers and their frameworks.  And they 
can do it with existing code, today, on older Pythons.  That, I think, is 
something worth working towards.