[Web-SIG] Specification process

[Ian Bicking]

Phillip J. Eby wrote:
> 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!

Well, they use [python.templating.engine], so I don't think it really 
fits your point ;)

When there's multiple consumers and producers, and none of them is more 
"core" than any other, the namespaces get a big vague.  If you use too 
"personal" of a namespace then people will (often rightly) see it as 
simply an expression of scope and a binding to the implementation.  If 
you use too general of a namespace you can overstep your bounds, 
self-declaring an authority you don't have.

Anyway, I want to set up another scope of authority, short of the 
formality of WSGI and the PEP process, but more authority than just 
personal namespaces.

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

I already did; there's three producers at this point: Routes, Selector, 
and Django.  Pylons and wsgicollection are both consumers, and other 
systems like CherryPy and paste.httpwrappers are likely to be consumers 
in the future.

The proposal doesn't match any of these systems, but it can be 
compatible with the functionality and purpose of all of them.  This 
seems like the exact situation where a common spec is called for -- the 
potential for compatibility exists, but isn't realized without some 
basic neutral documentation of a common layer.  If compatibility 
*already* existed than the ad hoc approach would have worked.  If 
compatibility wouldn't work, then the spec isn't useful.

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

Sure, and I wouldn't bring it up if it wasn't an actual issue.

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

Is there any way to plug in validation?  I like the idea of including 
validators.  Maybe an entry point(s):

[wsgiref.validate.environ]
key_name = validator_func

[wsgiref.validate.app_iter]
any_name = validator_func

[wsgiref.validate.start_response]
any_name = validator_func

The last would take the (status, headers, exc_info) values.  Hmm... I 
guess also a validator for the start response writer, though there's 
nothing very interesting you can do with that.  And maybe "*" for a 
keyname for wsgiref.validate.environ, which would validate the entire 
environment.

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

I'm fine with that.  I think Web-SIG is a fine place for discussion, 
even if the discussion isn't universally applicable.  Otherwise Web-SIG 
would be dead silent ;)

So, maybe two namespace options:

wsgiorg.*
websig.*

I personally prefer wsgiorg, since we can do this on wsgi.org, and I 
like what the name implies.


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