[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 06:37 PM 1/30/04 -0600, Ian Bicking wrote:
>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.

YAGNI.  Framework-specific communication can easily -- and therefore should 
-- occur via framework-specific interfaces.  There is absolutely no need 
for it in the interface.  Ergo, it shouldn't be there.  Entities should not 
be multiplied beyond necessity.


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

Unmaintainable messes grow from small hacks.  You fertilize them with 
neglect, water them with tears...  sorry, Babylon 5 reference.  :)


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

I'm sure they will.  And they'll be in violation of the spec.  Providing a 
backchannel won't improve the spec - it'll just lead to balkanized 
practices and adhoc extension.  But, well-defined complementary protocols 
are a plus: if e.g. the Webware "side protocol" becomes popular, other 
containers might offer the info, and it might eventually make its way into 
a new WSGI version.  But I absolutely do not want even the slightest 
confusion before then that the side protocol is in any way a part of WSGI.

Many people develop systems by copy-paste-modify from existing 
examples.  That means that people will copy code with the nonstandard 
keywords, along with the processing code for them, thinking it's some part 
of WSGI that's not covered in the spec, but hey, the code works, so it must 
be right...

Anyway, as you can see, this is a social issue, not a technical 
one.  Interfaces that go between different developers are *always* a social 
issue, and therefore deserve appropriate care in their social engineering.