[Web-SIG] Specification process

[Phillip J. Eby]

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

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


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

Fair enough.


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

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 
low (Internet-Drafts).


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



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


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