[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
Phillip J. Eby
pje at telecommunity.com
Sun Dec 7 19:05:26 EST 2003
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
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
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.
More information about the Web-SIG