[Web-SIG] Web Container Interface

[Steve Holden]

[...]
> 
> My gut feeling is that a barebones web container -- say, one that
> enables Quixote applications to run as FastCGI scripts, say -- should
> fit into 10 lines of Python code.  A super-duper, whiz-bang,
> all-singing, all-dancing container -- enable applications 
> written under
> N different frameworks to execute using M different models -- 
> should fit
> in roughly 1000 lines of Python.
> 
sprint!

> One big challenge I can foresee: the Python community will 
> never allow a
> standard web container interface to mandate a particular execution
> model, as the Java Servlet API does.  Writing a single API 
> that handles
> both Twisted/Medusa-style (event-driven I/O) and Java-style (threaded
> I/O) will be difficult; it might be impossible.  (Hmmm, maybe 
> there is a
> third model: traditional Unix-style (multiprocess I/O).)  I 
> would rather
> see two (three?) related APIs than one really complicated API 
> that tries
> to cover all the bases.
> 
That would be suitably Pythonic

> Finally, in reponse to a later remark by Philip (I think): I 
> definitely
> like calling the things that web developers write "web applications".
> "Web service" implies to me a special case of web application 
> that does
> not have a human user interface.  And I'm perfectly 
> comfortable calling
> the software that runs web applications an "application container".
> "Application engine" and "application server" also make sense to me.
> Whatever terminology we pick, it should be carefully defined in that
> PEP!
> 
This all sounds reasonable.

regards
 Steve