[Web-SIG] Specification process

[Phillip J. Eby]

At 11:20 AM 11/1/2006 -0600, Ian Bicking wrote:
>So I've got a couple specs out there that build on WSGI, and hopefully
>other people will be introducing more.  These specs are (or should be)
>fairly light and optional, suggesting useful compatibilities between
>WSGI components rather than anything that changes WSGI itself.  So I
>don't think we need a very heavy process, but we need some process.
>
>Does anyone have a suggestion?

My suggestion is that WSGI extensions should be proposed using a 
proposer-owned namespace (e.g. "selector.vars" in the url_vars case), and 
simply published by the proposer, with an announcement to the Web-SIG

For actualy *standardization*, I think that there should be some *positive* 
action from other people required.  Standardization implies that something 
is useful and reasonably non-problematic, but I'm not convinced that e.g. 
the POST parsing stuff that's currently on the table is 
non-problematic.  I'd want to see actual *implementations* of the proposal 
in a couple of widely-used frameworks before I'd consider it standards-worthy.

Frankly, I'd like to err on the side of TOO MUCH process for WSGI 
extensions than too little.  There is very little need for many of the 
extensions that get proposed, and often the proposals come with too high a 
price tag attached.  Meanwhile, if a proposal is something useful, it can 
*easily* become a defacto standard.

In fact, I think that further protocol standardization in WSGI is mostly 
bad design at the community level.  We should encourage sharing 
*implementations* first, before sharing interfaces.

So, I'm at a very strong -1 on having a simple process for defining WSGI 
extensions; the whole point of namespaced environ variables is to allow you 
to define your *own*; there is really no reason for everything to be named 
'wsgi.something'.


>Like I said, I don't want to make this a big complicated process,

I do.  :)  Well, actually, I suggest that there be a *really* simple 
process: just publish your own specs under your own package namespace, 
announce it to Web-SIG, and let other people use it if they like it.

But if you want to play in the wsgi.* namespace, it *should* be a big 
complicated process.


>People are always free to
>ignore these specifications, so it's really just as much a matter of
>getting a couple people to agree on some useful compatibility,

Great.  But let's please do it *outside* the wsgi.* namespace, and remember 
that if you share *implementations*, you don't need to duplicate any code, 
or have as much discussion about how stuff works inside.  People will 
either like it or not, and use it or not.  That's as low of a process bar 
as can be managed.

It's probably the case that some people don't feel that their extension is 
as valued by the community if it doesn't go in wsgi.*.  But that's just 
their lack of self-esteem talking.  If I ever come up with WSGI extensions, 
they're going to go under my name or a framework name.  If two or three 
other frameworks copy me, *then* I might talk about proposing adding it to 
the wsgi.* space, and I still wouldn't expect the proposal to get a free 
pass from the Web-SIG just because it's me.

To be honest, I don't think that the routing_args thing is *really* worthy 
of a wsgi.* namespace, it's just that with its problems fixed, it's not so 
much of a threat that it's worth fighting over.  And to some extent, I'm 
giving it a pass because it's you.  ;)  But if this is just the start of a 
wave of people demanding that *their* extensions get in too, then I'm all 
in favor of slamming the door on it to help keep the rest out.

IMO, wsgi.* standardization needs a PEP-sized or stdlib-inclusion-sized bar 
to it, since everyone is perfectly free to use their own namespaces for 
extensions, even ones they intend to offer as published interfaces for 
others to conform to.


>and not
>everything has to be universally applicable or useful.

If you're going to put it in 'wsgi.*', I think it must at least "do no 
harm".  I'm okay with the wsgi.routing_args thing, because at worst it's 
superfluous.  The POST stuff, I still think is dangerously likely to be 
overused.

Overenthusiasm for standardization is dangerous at this stage of WSGI's 
adoption.  WSGI itself is still not well-understood by the Python developer 
audience at large; for example, a recent IBM Developerworks article about 
WSGI contained some *serious* errors in its example middleware, which was 
terribly non-compliant, as the author would've seen if he'd run it with 
wsgiref.validate or paste.lint on both sides of it.

I guess what I'm saying is, it's bloody hard enough sometimes just to get 
people to write things that actually conform to the spec we have now, 
without adding a bunch of new ones.  (Hell, we should probably require that 
proposed "standard" extensions include patches to wsgiref.validate that 
verify correct operation of the extensions!)