[Web-SIG] Web Container Interface
Phillip J. Eby
pje at telecommunity.com
Fri Jan 30 18:46:23 EST 2004
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.)
More information about the Web-SIG