[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 04:29 PM 1/30/04 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>So far, it seems to me that this could be done with the two pieces of 
>>information mentioned above.  That is, whether the app will (potentially) 
>>be run in multiple processes, and whether it will (potentially) be run in 
>>multiple threads.  If the conditions are unacceptable to the service, it 
>>should raise an error immediately upon receipt of this information.
>
>We should also indicate if the server is long-running (the only 
>non-long-running instance being CGI).  Of course, a long-running server 
>may still only serve one request and be shut down, but there's lots of 
>optimizations and caching you might want to do in a long-running process 
>that aren't useful for a single-request process, and some applications may 
>be useless in a short-running environment (e.g., the multi-request 
>database transaction example).
>
>Otherwise I suppose I'm okay with the rest (even if I would like a real 
>reference to the gateway).  I can implement Webware using just this 
>interface.  The open keyword arguments allow me to extend this as well, 
>e.g., the Webware Application displays AppServer configuration parameters 
>in the web control panel, so I really would like a reference, even if it's 
>not required.  So actually I'm A-OK with the proposal.

My intention was that additional keywords be reserved for future WSGI 
versions, *not* become a way to sneak unspecified information into the 
interface.  Private communications are always possible through 
framework-specific mechanisms, such as sniffing for a 'giveMeWebwareInfo()' 
method that the container can call, or implementation of a particular 
interface, subclassing from a particular base, etc. etc.

Thing is, your Application won't be able to display that AppServer stuff 
*unless* it's being run under an AppServer.  And, there's no point in the 
AppServer telling non-Webware applications they're being run under it.  So, 
it should introspect you using Webware-specific techniques, and call 
Webware-specific methods in that event.  In other words, a typesafe 
mechanism agreed upon by both sides of the (Webware-specific) protocol.

If it's not defined in the standard, I don't want it allowed by the 
standard.  Let it be some other standard, like the "Webware service 
metadata extension to WSGI", that defines how you can make your service 
receive extra data when it's run in a Webware container.  There's nothing 
wrong with having such protocol extensions, but they should not be part of 
the base protocol's methods.  And I don't want to build "bags of data" into 
the base protocol with "extension info" that you then have to sift through 
to find things, when we could easily just have different methods that are 
part of other protocols.

(Indeed, I'm beginning to wonder if WSGI methods should all have some sort 
of prefix or suffix on them to help thoroughly disambiguate them from 
extended protocols.  E.g. 'runWSGI()', 'setupWSGI()' etc.)