[Web-SIG] Specification process
Phillip J. Eby
pje at telecommunity.com
Wed Nov 1 20:35:12 CET 2006
At 12:47 PM 11/1/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>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
>That's a bit awkward. There's no suggestion of any even light authority
>to such a specification. Just a "hey, here's what I'm using".
Well, that's what it *is*. Standardization, IMO, implies considerably more
I specifically *don't* want these things to get WSGI-class "authority" from
a lightweight process. That is *precisely* what I don't want. If specs
want to run with the big dogs, let 'em deal with the fleas.
Compare for example, with the very successful TurboGears/CherryPy
templating standard. That's working out quite nicely, with no "official"
standardization or authority, under its *own* name. They didn't see a need
to put it under a 'setuptools' namespace, just because setuptools' entry
point system is the glue that allows the interfaces to hook in!
Ultimately, granting authority cheaply just results in the authority being
> I think we can do better than that.
Sure - if you want to put in the rigor to do it right. I don't want it
implied that these "lightweight" specs are anything but lightweight.
>If you are really uncomfortable with "wsgi." we can just use another
>namespace. I don't want to use a namespace owned by a package; I feel
>strongly about that. These specs are neutral ground. But if we just
>specify a process associated with some new namespace (maybe "wsgiorg")
>that's fine with me. If that means we can use a lighter process, I will
>eagerly use such a namespace.
How about "experimental.whatever"? :)
>By suggesting a quorum, which implies some minimum number of people who
>support a proposal, I was suggesting that some positive action be
>required. This is largely intended to avoid specs going forward simply
>because no one cares or is paying attention.
>I'm trying to propose specifications that can usefully have more than one
>implementation (url vars),
To be honest, I can only think of some very obscure use cases for
that. The only reason you need the routing_args in environ is if you have
to pass through some other WSGI component between the routing and the place
where the arguments get used. I haven't come up with a real world example
where that would happen, because normally a piece of routing middleware is
going to be directly invoking the thing whose arguments were just obtained.
Does anybody actually have an *example* of this use case? Or is there some
other use case I'm just not seeing? Honestly, it seems like
standardization for standardization's sake to me, and that's what I'm
Now, I'm *not* opposed to having a published, peer-reviewed spec. That's
great! Do lots more of them. What I *am* opposed to is treating what are
effectively Internet-Draft specs as if they were RFCs. Let's keep the
standardization bar high (RFC), and the experimentation/communication bar
>or where the implementation may be embedded in a larger existing system
>that does not currently make it easy to introduce a new dependency or
>factoring of the code (post form).
I don't see how this works for newly-proposed standards, which presumably
don't have implementations yet. We should encourage lightweight, decoupled
implementations, and not reward embedding and spaghettiware. This is in
fact why I generally dislike middleware that adds junk to environ, as this
leads to WSGhettI code. :)
Frankly, if an application knows that the middleware *exists*, then there
is no point to having it. The point of middleware is to be *invisible* to
applications, otherwise it's not middleware, it's a framework.
And just because you "standardize" it, doesn't make it any less of a
framework. It just makes it a framework with more overhead, in both
procedure *and* code. :)
>>>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
>I call "consenting adults" on you here!
The bar for entrance to wsgi.* should be as high as that for the standard
library, and the "do no harm" rule applies there too.
>I think we are at a point when there are multiple people moving WSGI-based
>components forward from different directions, and we're ready to start
>cooperating at a higher level. Obviously there are problems that can
>arise, which is why I would encourage peer review in this form.
+1 peer review. +1 proposals and discussion and interbreeding and all
manner of good things. I'm only -1 on there being a low bar for getting to
put 'wsgi' in the name of the result.
wsgi.* specs should at minimum include code to allow wsgiref.validate to
validate implementations, and reference implementation(s) suitable for
inclusion in wsgiref. I think that this is a reasonable bar to set for
something that's getting called "standard" and given any "authority".
If you want to have "authority" for these fast-track experimental
proposals, create another group name, and let its proposals gain whatever
authority it deserves. Call it the "Python Web Interfaces Group" or
something, and put the stuff in 'p_wig.*' or some such. :) Or how about
>And hey, we already have a rejected proposal! (It didn't actually get as
>far as the mailing list, but it's on the website.) So the system works,
>this isn't just about moving stuff through.
>But ultimately if this turns into a cabal of like-minded WSGI-oriented
>individuals agreeing on things they think are interesting and useful, I'm
>actually okay with that. I don't know if that reveals an inner
>dictatorial tendency, or just a desire for expedient forward movement
>that's otherwise hard to achieve when there's no umbrella project or
>hierarchy of concepts.
By all means, create a cabal! I'm totally in favor. Just don't try to
overstate its actual authority. If the cabal produces good work, it will
gain authority from its reputation, under its *own* name.
In marketing, "brand extension" is often fatal. For a recent example,
notice that Google wised up and bought YouTube, which was a better brand
than "Google Video". Assuming your cabal does good work, it will actually
have more impact through independence, whereas mixing everything in under
the WSGI name just dilutes the brand for everybody.
More information about the Web-SIG