Re: [Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

2010-01-07 Thread Gustavo Narea
Hello, Aaron. Aaron said: > I think path dispatch considerations do not belong at the level > of the WSGI spec. Higher level layers should worry about > exactly how the URL gets dispatched within the application. I agree -- That's why I believe the wsgiorg.routing_args Specification is the righ

Re: [Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

2010-01-07 Thread Aaron Watters
"whiff.entry_point" and "whiff.template_path" etc. Or maybe I misunderstand something. -- Aaron Watters --- On Wed, 1/6/10, Gustavo Narea wrote: > From: Gustavo Narea > Subject: Re: [Web-SIG] wsgiorg.routing_path addition to the > wsgiorg.routing_args Specifica

Re: [Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

2010-01-06 Thread Gustavo Narea
Is it a really bad suggestion? :( - G. On Mon, Jan 4, 2010 at 11:31 PM, Gustavo Narea wrote: > Hello everybody. > > The current wsgiorg.routing_args specification requires that "Portions of > the > path that have been parsed should still be moved to SCRIPT_NAME (and > removed > from PATH_INFO)

[Web-SIG] wsgiorg.routing_path addition to the wsgiorg.routing_args Specification

2010-01-04 Thread Gustavo Narea
Hello everybody. The current wsgiorg.routing_args specification requires that "Portions of the path that have been parsed should still be moved to SCRIPT_NAME (and removed from PATH_INFO)", but: 1.- That's against semantics. According to PEP 333 and the CGI spec, SCRIPT_NAME and PATH_INFO mus