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

[Phillip J. Eby]

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?  :)

My thought here was that many kinds of Python frameworks have objects with 
'run' methods, and they all have different signatures.  So, explicit being 
better than implicit, I chose a name that was midway between a nameless 
callable and, say, 'executeWebRequest'.  :)

I'm not too strongly attached to the name, but would like to keep it a bit 
more explicit than 'run()' or a bare callable.


> > Containers that can run multiple requests in parallel, *should* also
> > provide the option of running an application in a single-threaded
> > fashion, so that applications or frameworks that are not thread-safe
> > may still be used.
>
>Should there also be a is_thread_safe() method that returns a Boolean,
>so containers can serialize if necessary?

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.

Second, if container configuration becomes complex, there's always the 
possibility to go back and create some kind of "deployment descriptor" 
spec, to make apps deployable in a variety of containers.  But I think that 
should wait until there's enough field experience with *this* spec, to know 
what's really needed for the deployment spec.

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.  :)


> > The rationale for requiring a dictionary is to maximize portability
> > between containers.  The alternative would be to define here some
> > subset of a dictionary's methods as being the standard and portable
> > interface.  In practice, however, most containers will probably want
>
>Note that the UserDict.DictMixin class implements all of the other
>dictionary methods as long as you implement __getitem__, __setitem__,
>__delitem__, and keys().  It seems unpythonic to require a particular class
>here.

Maybe I'm overreacting to being burned by imperfect dictionary simulations 
in the past.  OTOH, I noticed you haven't actually given a use case for 
*not* using a dictionary.  :)

However, there is ample precedent in Python for requiring at least a 
*subclass* of dictionary, and perhaps we could compromise there.


>The spec looks very good, though -- simple, easy to implement, and useful.

Thanks.  I've often found this "plumbing" issue to be quite annoying.  I 
know that I personally would likely experiment with more web app 
frameworks, if I knew that I could plug them into a container I was already 
familiar with.  And, I recently finished developing a very nice 
multiprocess FastCGI container which I expect to be my main runtime 
environment for web applications in future.  I don't want it to only be 
useful for myself and other PEAK users, though.  Hence, the spec.