[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
Phillip J. Eby
pje at telecommunity.com
Mon Dec 8 10:18:25 EST 2003
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
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.
>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.
>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.
More information about the Web-SIG