[Web-SIG] Specification process
Phillip J. Eby
pje at telecommunity.com
Wed Nov 1 19:01:36 CET 2006
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!)
More information about the Web-SIG
mailing list