[Web-SIG] Web Container Interface

[Ian Bicking]

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:

application.setup(..., webKitAppServer=self)

Application has:

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

> 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 
the spec's.

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

> (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