[Web-SIG] wsgi.url_vars feedback

[Phillip J. Eby]

At 05:42 PM 10/31/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
>>>Anyway, I've updated the spec:
>>>
>>>http://wsgi.org/wsgi/Specifications/url_vars
>>>http://wsgi.org/wsgi/Specifications/url_vars?action=diff
>>>
>>>Is everyone happy with this version?
>>I still think it should be url_args rather than url_vars -- I don't see 
>>any reason why they could be considered "variables" rather than 
>>arguments.  :)  But other than that, and the desire to see clarification 
>>about */** as an intended/supported use case, I give it a +1.
>
>I was thinking about variables similar to GET and POST variables, which 
>seems to be the most common way to refer to them.  (Of course GET 
>variables are actually query string variables, which is orthogonal to the 
>request method, but so it goes.)

That would actually be another reason *not* to use "vars", because these 
aren't the same things.  They're something that's framework-specific, not 
part of the nature of HTTP.  I would actually suggest that url_params would 
be better, except that URLs *do* have something called parameters.

If you *must* have vars, please call it wsgi.routing_vars or 
wsgi.dispatch_vars instead, so at least it will be clearly distinguishable 
from other URL variables.  In fact, wsgi.dispatch_arguments would probably 
be the *most* descriptive name for what these actually are.  Note that 
there isn't any requirement here that the data even comes from the URL!