On 11/1/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Luke Arno wrote:
> > On 11/1/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> >>
> >> So, maybe two namespace options:
> >>
> >> wsgiorg.*
> >> websig.*
> >>
> >> I personally prefer wsgiorg, since we can do this on wsgi.org, and I
> >> like what the
Luke Arno wrote:
> On 11/1/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>
>> 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.
>
> +1 for wsgiorg as a neutral namespace for building
At 04:18 PM 11/1/2006 -0500, Luke Arno wrote:
>What additional value comes from lending
>"authority" to this convention (url vars)? Bah! ;)
Exactly my point. Let a thousand flowers bloom in other namespaces. :)
___
Web-SIG mailing list
Web-SIG@python.
On 11/1/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> 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.
+1 for wsgiorg as a neutral namespace for building
compatibility. -1 for process u
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 bec
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,
On Nov 1, 2006, at 9:33 AM, Phillip J. Eby wrote:
> Yep, that was my reasoning; I think its most valuable use is as
> arguments
> to a callable, such that a dispatcher or routing system would just
> invoke a
> callable with some framework-defined arguments, combined with the *
> and **
> fro
Robert Brewer wrote:
> Ian Bicking wrote:
>> One little question: if a dispatcher can never produce
>> one of the kinds of information (which happens for some
>> of them), should they put in an empty list/tuple or
>> empty dict, or should they put in None for that item?
>> I'm currently saying they
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
Ian Bicking wrote:
> One little question: if a dispatcher can never produce
> one of the kinds of information (which happens for some
> of them), should they put in an empty list/tuple or
> empty dict, or should they put in None for that item?
> I'm currently saying they must put in a list/tuple or
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
At 11:10 AM 11/1/2006 -0600, Ian Bicking wrote:
>I don't really care that much, somehow url_vars just seemed the most
>natural choice and I hardly even thought about it. Of course "URLs" don't
>even exist (though I'm still fuzzy on why), so obviously the terminology
>is a bit crude. And really
On 11/1/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Probably the name I like the most of what you've suggested would be
> "wsgi.routing_args", since that makes me think of "things that were
> captured on the way here" ("routing" more so than "dispatch").
> Actually, I don't really feel any strong
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
Phillip J. Eby wrote:
> 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=
I've updated this specification in response to input, mostly changing
language but not the meat of the specification itself:
http://wsgi.org/wsgi/Specifications/handling_post_forms
http://wsgi.org/wsgi/Specifications/handling_post_forms?action=diff
One thing that occurred to me is that wsgi.inpu
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
17 matches
Mail list logo
