Re: [Web-SIG] Adding wsgiref to stdlib
It still looks like an application of WSGI, not part of a reference implementation. It seems to me that canonical exemplars are part of what a reference implementation should include. Otherwise it would be a standard implementation, which is considerably different. Bill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
Guido van Rossum wrote: PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0; it's written by Phillip Eby who put a lot of effort in it to make it acceptable to very diverse web frameworks. The PEP has been well received by web framework makers and users. As a supplement to the PEP, Phillip has written a reference implementation, wsgiref. I don't know how many people have used wsgiref; I'm using it myself for an intranet webserver and am very happy with it. (I'm asking Phillip to post the URL for the current source; searching for it produces multiple repositories.) I believe that it would be a good idea to add wsgiref to the stdlib, after some minor cleanups such as removing the extra blank lines that Phillip puts in his code. Having standard library support will remove the last reason web framework developers might have to resist adopting WSGI, and the resulting standardization will help web framework users. I'd like to include paste.lint with that as well (as wsgiref.lint or whatever). Since the last discussion I enumerated in the docstring all the checks it does. There's still some outstanding issues, mostly where I'm not sure if it is too restrictive (marked with @@ in the source). It's at: http://svn.pythonpaste.org/Paste/trunk/paste/lint.py I think another useful addition would be some prefix-based dispatcher, similar to paste.urlmap (but probably a bit simpler): http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py The motivation there is to give people the basic tools to simple multi-application hosting, and in the process implicitly suggest how other dispatching can be done. I think this is something that doesn't occur to people naturally, and they see it as a flaw in the server (that the server doesn't have a dispatching feature), and the result is either frustration, griping, or bad kludges. By including a basic implementation of WSGI-based dispatching the standard library can lead people in the right direction for more sophisticated dispatching. And prefix dispatching is also quite useful on its own, it's not just educational. Last time this was brought up there were feature requests and discussion on how industrial strength the webserver in wsgiref ought to be but nothing like the flamefest that setuptools caused (no comments please). No one disagreed with the basic premise though, just some questions about the particulars of the server. I think there were at least a couple small suggestions for the wsgiref server; in particular maybe a slight refactoring to make it easier to use with https. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
Guido van Rossum wrote:
I think another useful addition would be some prefix-based dispatcher,
similar to paste.urlmap (but probably a bit simpler):
http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
IMO this is getting into framework design. Perhaps something like this
could be added in 2.6?
I don't think it's frameworky. It could be used to build a very
primitive framework, but even then it's not a particularly useful
starting point.
In Paste this would generally be used below any framework (or above I
guess, depending on which side is up). You'd pass /blog to a blog
app, /cms to a cms app, etc. WSGI already is very specific about what
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
PATH_INFO), and that's all that the dispatching needs to do.
The applications themselves are written in some framework with internal
notions of URL dispatching, but this doesn't infringe upon those.
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
that's their problem, as the dispatcher is just using what's already
allowed for in the WSGI spec.) It also doesn't overlap with frameworks,
as prefix-based dispatching isn't really that useful in a framework.
The basic implementation is:
class PrefixDispatch(object):
def __init__(self):
self.applications = {}
def add_application(self, prefix, app):
self.applications[prefix] = app
def __call__(self, environ, start_response):
apps = sorted(self.applications.items(),
key=lambda x: -len(x[0]))
path_info = environ.get('PATH_INFO', '')
for prefix, app in apps:
if not path_info.startswith(prefix):
continue
environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
environ['PATH_INFO'] = environ.get('PATH_INFO',
'')[len(prefix):]
return app(environ, start_response)
start_response('404 Not Found', [('Content-type', 'text/html')])
return ['htmlbodyh1Not Found/h1/body/html']
There's a bunch of checks that should take place (most related to /'s),
and the not found response should be configurable (probably as an
application that can be passed in as an argument). But that's most of
what it should do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
It still looks like an application of WSGI, not part of a reference
implementation. Multiple apps looks like an advanced topic to me; more
something that the infrastructure (Apache server or whatever) ought to
take care of.
I don't expect you to agree with me. But I don't expect you to be able
to convince me either. Maybe you can convince Phillip; I'm going to
try to sit on my hands now.
--Guido
On 4/28/06, Ian Bicking [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I think another useful addition would be some prefix-based dispatcher,
similar to paste.urlmap (but probably a bit simpler):
http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
IMO this is getting into framework design. Perhaps something like this
could be added in 2.6?
I don't think it's frameworky. It could be used to build a very
primitive framework, but even then it's not a particularly useful
starting point.
In Paste this would generally be used below any framework (or above I
guess, depending on which side is up). You'd pass /blog to a blog
app, /cms to a cms app, etc. WSGI already is very specific about what
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
PATH_INFO), and that's all that the dispatching needs to do.
The applications themselves are written in some framework with internal
notions of URL dispatching, but this doesn't infringe upon those.
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
that's their problem, as the dispatcher is just using what's already
allowed for in the WSGI spec.) It also doesn't overlap with frameworks,
as prefix-based dispatching isn't really that useful in a framework.
The basic implementation is:
class PrefixDispatch(object):
def __init__(self):
self.applications = {}
def add_application(self, prefix, app):
self.applications[prefix] = app
def __call__(self, environ, start_response):
apps = sorted(self.applications.items(),
key=lambda x: -len(x[0]))
path_info = environ.get('PATH_INFO', '')
for prefix, app in apps:
if not path_info.startswith(prefix):
continue
environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
environ['PATH_INFO'] = environ.get('PATH_INFO',
'')[len(prefix):]
return app(environ, start_response)
start_response('404 Not Found', [('Content-type', 'text/html')])
return ['htmlbodyh1Not Found/h1/body/html']
There's a bunch of checks that should take place (most related to /'s),
and the not found response should be configurable (probably as an
application that can be passed in as an argument). But that's most of
what it should do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
Guido van Rossum wrote: It still looks like an application of WSGI, not part of a reference implementation. Multiple apps looks like an advanced topic to me; more something that the infrastructure (Apache server or whatever) ought to take care of. I don't understand the distinction between application of WSGI and reference implementation. The reference implementation *is* an application of WSGI... using the reference implementation doesn't make something more or less WSGI. Also, wsgiref *is* infrastructure. When using the HTTP server, there is no other infrastructure, there is nothing else that will do this prefix dispatching for you. Apache and other web servers also provides this functionality, and with the right configuration it will provide the identical environment as a prefix dispatcher. To me that's a positive. I've seen cases where other people have done the same prefix dispatching in Python *without* matching the interface of anybody else's code or environment; that's the sort of thing a reference implementation is meant to keep people from doing. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote: It still looks like an application of WSGI, not part of a reference implementation. Multiple apps looks like an advanced topic to me; more something that the infrastructure (Apache server or whatever) ought to take care of. I'm fine with a super-simple implementation that emphasizes the concept, not feature-richness. A simple dict-based implementation showcases both the wsgiref function for path shifting, and the idea of composing an application out of mini-applications. (The point is to demonstrate how people can compose WSGI applications *without* needing a framework.) But I don't think that this demo should be a prefix mapper; people doing more sophisticated routing can use Paste or Routes. If it's small enough, I'd say to add this mapper to wsgiref.util, or if Guido is strongly set against it being in the code, we should at least put it in the documentation as an example of how to use 'shift_path_info()' in wsgiref.util. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Adding wsgiref to stdlib
On 4/28/06, Phillip J. Eby [EMAIL PROTECTED] wrote: If it's small enough, I'd say to add this mapper to wsgiref.util, or if Guido is strongly set against it being in the code, we should at least put it in the documentation as an example of how to use 'shift_path_info()' in wsgiref.util. I'm for doing what you think is best. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
