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