[Web-SIG] Specification process

[Ian Bicking]

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".  I think 
we can do better than that.

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.

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

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.

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

There are implementations associated with both specifications.  There's 
no implementors of the specifications themselves, because the 
specifications didn't yet exist.  But there are things that should use 
the specification, if a specification existed.

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

I'm trying to propose specifications that can usefully have more than 
one implementation (url vars), 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).

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

I call "consenting adults" on you here!  But anyway, I'm now more 
interested in the other direction I mentioned, attaching an attribute to 
wsgi.input that gives the decoded form.

> 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!)

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.

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.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org