Alan Kennedy wrote: >> I'm not set on "production" quality code, but I think the general >> sentiment against that is entirely premature. The implementations >> brought up -- CherryPy's >> (http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's >> (http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and >> wsgiref's >> (http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2&view=markup) >> >> are all pretty short. It would be better to discuss the particulars. >> Is there a code path in one or more of these servers which you think >> is unneeded and problematic? > > > A few points. > > 1. My opinion is not relevant to whether/which WSGI server goes into the > standard library. What's required is for someone to propose to > python-dev that a particular WSGI server should go into the standard > library. I imagine that the response on python-dev to the proposer is > going to be along the lines of "Will you be maintaining this?" If/when > python-dev is happy, then it'll go into the distribution. > > 2. What's wrong with leaving the current situation as-is, i.e. the > available WSGI implementations are listed on the WSGI Moin page > > http://wiki.python.org/moin/WSGIImplementations
I think a WSGI HTTP server is considerably more useful than SimpleHTTPServer, for a whole bunch of reasons. With a WSGI HTTP server, I see little reason for anyone to use any of the other Simple*Server implementations (unless perhaps they are using async processing, which WSGI does not facilitate, but I think is doable with SimpleHTTPServer). > 3. If I had to pick one of the 3 you suggested, I'd pick the last one, > i.e. PJE's, because it fulfills exactly the criteria I listed > > - It's pretty much the simplest possible implementation, meaning it's > easiest to understand. In part this is because it uses the other parts of wsgiref, which the other servers do not. > - It's based on the existing *HttpServer hierarchy All three share this property. > - It's got a big notice at the top saying """This is both an example of > how WSGI can be implemented, and a basis for running simple web > applications on a local machine, such as might be done when testing or > debugging an application. It has not been reviewed for security issues, > however, and we strongly recommend that you use a "real" web server for > production use.""" And of course this is one of the easiest features to port ;) But anyway, maybe the standard library isn't the right place for any of these, maybe it wasn't the right place for SimpleHTTPServer (though it's hard to actually argue that, since in practical terms SimpleHTTPServer has been very successful). But we could also just create a stand-alone package that provides just an HTTP server, and reference that from wherever appropriate (including the standard library documentation). Right now the standard library documentation doesn't often reference external packages. I don't know if there's any real reason for that. I will posit that no, there is no good reason that the stdlib documentation shouldn't link directly to projects (at least in certain situations). I think we have enough implementations to take from to make such a canonical HTTP package, at least within the scope of threaded HTTP implementations based on SimpleHTTPServer. Though then there's the whole Twisted question -- but right now packaging and scope make it hard to actually use Twisted in these same situations. But given a specific API, at least that would give Twisted a clear target so that instead of "from httpserver import HTTPServer" you'd do "from twisted.httpserver import HTTPServer" and then you'd be running under Twisted (ignoring scenarios where Twisted does more than HTTP serving, which is out of scope here). Of course, then you could say "lets create a multi-protocol app server package" integrating perhaps portions of Flup, an HTTP server, and a couple other things (but there's not a whole lot else I imagine going into this stuff). And then the scope starts to match Twisted, except perhaps with a simplification that you'd only handle request/response-style protocols with blocking WSGI-style responders. Then you could say, hey, isn't WSGI meant to keep us from having to do these combined efforts, because multiple packages are okay if they all implement the same standard? Then you could say, sure, but it also means that we can combine packages on a different timescale and structure than higher-level frameworks (WSGI applications), waiting until the time is ripe, and maybe the time is ripe. It feels lame (to me) to tell people to use one package or another as they switch from HTTP to SCGI to whatever. Then-you-could-saying'ly y'rs... -- 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
