[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
stuart at stuartbishop.net
Sun Dec 7 22:50:22 EST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On 08/12/2003, at 11:05 AM, Phillip J. Eby wrote:
> At 04:35 PM 12/7/03 -0500, A.M. Kuchling wrote:
>> On Sun, Dec 07, 2003 at 01:53:43PM -0500, Phillip J. Eby wrote:
>> > to a request made on a Web server. A container invokes an
>> > by calling its ``runCGI`` method, whose signature is defined as
>> Name nit: why include the irrelevant 'CGI' in the name? Just 'run()'
>> be fine.
> Well, if you're going to go that route, why not just make it a
> callable? :)
Callable or something simpler and more obvious like 'run()' is good if
you exect objects to only talk to one protocol. doCGI is ok (I'd prefer
handle_CGI...) if you think a single object might also want to handle
other protocols (XMLRPC, FTP), as defined by future PEPs.
> I thought about it. But there are going to be more applications than
> containers, so why put extra burden on the app side to benefit the few
> containers that will be threaded? My conclusion (which others might
> not share) was that such containers are going to need other per-app
> configuration settings anyway, like perhaps the path at which the app
> is located, how many threads maximum to use in a thread pool for that
> app, and of course how to get the app object in the first place.
> Thus, there's little added burden for the container to require
> explicit configuration for threadedness. It's also possible that what
> constitutes thread-safety might vary somewhat from container to
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),
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.
> 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. 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 :-)
Stuart Bishop <stuart at stuartbishop.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
More information about the Web-SIG