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

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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 
>> application
>> > by calling its ``runCGI`` method, whose signature is defined as
>>
>> Name nit: why include the irrelevant 'CGI' in the name?  Just 'run()' 
>> would
>> 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 
> container.

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>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/0/T+AfqZj7rGN0oRArAvAKCZ3FLT/kcdF7sKAYWd6e0C8+w8nACdFRw1
0kKa88u1VA8f110rJei6KPQ=
=YCkJ
-----END PGP SIGNATURE-----