[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
Phillip J. Eby
pje at telecommunity.com
Wed Dec 10 18:42:39 EST 2003
At 02:15 PM 12/10/03 -0500, Michael C. Neel wrote:
>One is how willing are developers of the current systems to rewrite or
>provide a wrapper for this new one? Off the top of my head I know
>mod_python has for it: (it's own) PSP and Publisher, Albatross, Spyce,
>and Draco. Can we really expect all of these to update to use this new
>standard? Or do we just want mod_python to expose another interface?
Yes. But note that it's not necessarily the authors of mod_python that
have to provide it. Somebody that wants to run PyWCI apps under mod_python
could write a PyWCI container that runs under the existing mod_python
API. However, somebody would only need to write this once, for everybody
to be able to take advantage of it under mod_python. And, other frameworks
would need only to expose a PyWCI-compliant 'runCGI' method, to be able to
run in that container (assuming that their process model was compatible).
>Which leads to my other concern; should this even be a concern? The
>goal here is to update/add to the stdlib.
That's a minor and mostly tangential concern for the proposal as such. I
posted the proposal here before putting it out in the wider world of
1) the proposal offers some direction for an interface between any new
stdlib container pieces and any application-like pieces
2) There's lots of web framework and container authors here, who presumably
have some interest in Python "web standards". So, I assumed that the best
peer review for early feedback would be found here.
So, my goals for the proposal are really orthogonal to the standard library
goals of the Web-SIG, but are nonetheless of interest to the Web-SIG
membership, if that makes sense.
>I freely admit I don't "get it" yet, and may be missing the bigger
>picture. This sounds to me like a Java server type of thing - a generic
>enough framework when I can take my app from one system to another with
>no changes needed.
Assuming that your threading and/or process model are compatible, yes, you
should have your choice of containers for physical deployment of the
app. But there are bigger gains than that to be had. See below.
> While I need my client side to be as flexible as
>possbible, it's extreamly rare that in pratice it's needed at the server
>side because it's rare the whole platform changes (and usally when it
>does it along with a rewrite/upgrade to the app anyway, making keeping
>the code even less useful).
That's all true, but not the point of the proposal. The issue is user
choice when initially *selecting* the container. Right now, your runtime
platform needs can drastically affect your options for what kind of
framework you can use, because what frameworks you can use depends heavily
on what kind of runtime container you need to support.
With widespread adoption of PyWCI, your container choice would not
significantly narrow your framework choice, and you would also have the
option of mixing frameworks by using a PyWCI-based request router.
So, it's not so much about being able to *move* your application (although
it's nice to know you can "move up" or "move sideways" as needed), as it is
about being able to have more choices in the first place.
The thing that creates user uncertainty about Python web programming right
now is *not* that there are dozens of choices. It's that you have to pick
*one*, and then you're probably stuck with it. And *none* of your learning
or runtime environment may stay with you if you switch. The mere
*existence* of a widely-supported container interface will be a significant
peace-of-mind booster for PHB's and developers alike.
>That said, I want anything in the stdlib to jive, so that if I change
>from one class to another (for the same role), they both expose the same
>interface. So in that scope, I see something like this being very
Yes, and this ties into my point about having a widely-supported
"standard". But, my intent is to bootstrap the standard into widespread
use, without necessarily going through the stdlib first.
In the past, Guido has seemed to me to prefer to base the stdlib on "de
facto" standards representing community experience, over "de jure"
standards representing what people think might be a good idea. Thus, if
PyWCI were widely implemented, that would be in itself a justification for
its use in the standard library, and thus beneficial to the Web-SIG's
efforts in that regard.
More information about the Web-SIG