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

[Phillip J. Eby]

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 
python-list, because:

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
>helpful.

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.