[Web-SIG] Web Container Interface
ianb at colorstudy.com
Fri Jan 30 19:37:11 EST 2004
On Jan 30, 2004, at 5:46 PM, Phillip J. Eby wrote:
>> 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.
I had a feeling you'd react this way ;) But I don't really see why it
would be so bad. AppServer calls:
def setup(..., webKitAppServer=None, **kw):
It's highly transparent what's happening. Since the spec leaves room
for future extension, I assume applications are required to accept
keywords they don't understand, and that they will ignore those
arguments, and that applications must provide default arguments for
values so that they support containers that don't provide those
> 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.
Obviously Application would have to accept None in place of the
AppServer, and react accordingly. That's my problem to deal with, not
> 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.
The one keyword is the only addition I'd make. Everything else would
be between Application and AppServer. Again, I really don't see the
problem. I don't see where this would cascade into some unmaintainable
> (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.)
I think setup() is rather generic, though it could be setupCGI and it
would be fine. I think you are overreacting. And hey, I just said
what someone else was eventually going to think of anyway.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG