From luke.arno at gmail.com Tue May 2 06:04:23 2006 From: luke.arno at gmail.com (Luke Arno) Date: Tue, 2 May 2006 00:04:23 -0400 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <445409DD.2090304@colorstudy.com> References: <44526DD3.4010807@colorstudy.com> <44527506.2070407@colorstudy.com> <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com> <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com> <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com> <5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com> <445409DD.2090304@colorstudy.com> Message-ID: I don't pipe up much but dispatch has been on my mind for a while as I have been working on this: http://lukearno.com/projects/selector/ I think dispatching is best left as an (obvious) exercise to the reader. What dispatching makes sense, what metaphor or technique should be applied, is situational. When I see other WSGI servers requiring a list of prefix/app pairs in their init signature, I am put off. The server's job is to translate HTTP (or SCGI, FCGI, etc.) to WSGI. Just do that. To me WSGI is not just the freedom of frameworks interoperating, but the freedom _from_ frameworks. The stack can be unbundled and I can pick the the best thing for my needs at each layer, ? la carte. - Luke http://lukearno.com/ From sh at defuze.org Tue May 2 10:11:27 2006 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 2 May 2006 09:11:27 +0100 (BST) Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib Message-ID: <9170.194.221.74.7.1146557487.squirrel@mail1.python-hosting.com> Hello all, I've been following the discussion around adding wsgiref to the stdlib and it sounds like a very good idea. However I'm a little concerned as it seems only wsgiref has been suggested to be included. I wonder if you guys intend to review other implementations before going ahead? I ask this because the simple_server.py module of wsgiref says: """It has not been reviewed for security issues, however, and we strongly recommend that you use a "real" web server for production use. """ Therefore, I wonder what is the final purpose of such addition? Is it merely to have default WSGI implementation that *might* not be scalable in production? I have nothing against wsgiref mind you. I'm fairly sure Phillip has done a great job but I simply wanted to know if you would consider checking other implemetations. - Sylvain From p.f.moore at gmail.com Tue May 2 15:48:03 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 2 May 2006 14:48:03 +0100 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com> References: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com> Message-ID: <79990c6b0605020648v7c66fd5dtdd4a1b24db14a8a8@mail.gmail.com> On 4/28/06, Phillip J. Eby wrote: > At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote: > >(I'm asking Phillip to post the URL for the current > >source; searching for it produces multiple repositories.) > > Source browsing: http://svn.eby-sarna.com/wsgiref/ > Anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref I'm not sure how dumb a question this is, but bear with me :-) >From reading this, it seems that there is no CGI-to-WSGI gateway in wsgiref. Would it be worth adding one (or did I miss it)? I'm thinking of a case where I have a WSGI application, but no easy way of hosting anything other than CGI. In that situation, being able to wrap my application in a CGI-to-WSGI gateway would be useful - and having one in the standard library would avoid me having to cut and paste the run_with_cgi code from PEP 333 into each of my scripts... Does this make any sense? Paul. From guido at python.org Tue May 2 16:39:22 2006 From: guido at python.org (Guido van Rossum) Date: Tue, 2 May 2006 07:39:22 -0700 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <9170.194.221.74.7.1146557487.squirrel@mail1.python-hosting.com> References: <9170.194.221.74.7.1146557487.squirrel@mail1.python-hosting.com> Message-ID: On 5/2/06, Sylvain Hellegouarch wrote: > I've been following the discussion around adding wsgiref to the stdlib and > it sounds like a very good idea. However I'm a little concerned as it > seems only wsgiref has been suggested to be included. I wonder if you guys > intend to review other implementations before going ahead? I ask this > because the simple_server.py module of wsgiref says: > > """It has not been reviewed for security issues, > however, and we strongly recommend that you use a "real" web server for > production use. > """ > > Therefore, I wonder what is the final purpose of such addition? Is it > merely to have default WSGI implementation that *might* not be scalable in > production? > > I have nothing against wsgiref mind you. I'm fairly sure Phillip has done > a great job but I simply wanted to know if you would consider checking > other implemetations. Anything that could be considered of sufficiently industrial strength to be secure and scalable in production would necessarily be such a large project, such a complex code base, and have such different release cycle that it would not make a good standard library candidate. (Think mod_python, Twisted, Zope, Apache; think tail wagging the doc.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) From sh at defuze.org Tue May 2 17:13:17 2006 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 2 May 2006 16:13:17 +0100 (BST) Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: References: <9170.194.221.74.7.1146557487.squirrel@mail1.python-hosting.com> Message-ID: <12825.194.221.74.7.1146582797.squirrel@mail1.python-hosting.com> > Anything that could be considered of sufficiently industrial strength > to be secure and scalable in production would necessarily be such a > large project, such a complex code base, and have such different > release cycle that it would not make a good standard library > candidate. (Think mod_python, Twisted, Zope, Apache; think tail > wagging the doc.) I was thinking into products that have shown good results over the last past year and are far less complex than the ones you mention. There are existing implementations that could be easily extracted from their environment and might be better: CherryPy, Paste, Pylons, Colubrid, etc. all offer what wsgiref provides (well to what I understand from wsgiref code, Phillip could correct my knowledge here). Nevertheless, it might be more useful to define the boundaries of including a WSGI implementation to the stdlib before even choosing one. AFAIK, WSGI is splitted into three distinct layers. A web server Some middlewares An application We will not include middlewares I believe. I'm not sure I would see the point of adding a default WSGI application. So we're left with the web server part to test and then see which is the one filling the best the criteria folks around here may decide to discriminate on. - Sylvain From pje at telecommunity.com Tue May 2 17:32:15 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 02 May 2006 11:32:15 -0400 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <79990c6b0605020648v7c66fd5dtdd4a1b24db14a8a8@mail.gmail.co m> References: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com> <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20060502112937.01e63008@mail.telecommunity.com> At 02:48 PM 5/2/2006 +0100, Paul Moore wrote: >On 4/28/06, Phillip J. Eby wrote: >>At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote: >> >(I'm asking Phillip to post the URL for the current >> >source; searching for it produces multiple repositories.) >> >>Source browsing: http://svn.eby-sarna.com/wsgiref/ >>Anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref > >I'm not sure how dumb a question this is, but bear with me :-) > > From reading this, it seems that there is no CGI-to-WSGI gateway in >wsgiref. There is, sort of: from wsgiref.handlers import CGIHandler CGIHandler().run(app) What the TODO is referring to is some kind of wrapper script that can be used to launch a deployed application. It's pending there being some kind of deployment standard for WSGI. From ianb at colorstudy.com Tue May 2 17:53:51 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 02 May 2006 10:53:51 -0500 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: References: <44526DD3.4010807@colorstudy.com> <44527506.2070407@colorstudy.com> <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com> <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com> <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com> <5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com> <445409DD.2090304@colorstudy.com> Message-ID: <4457808F.2030403@colorstudy.com> Luke Arno wrote: > I don't pipe up much but dispatch has been on my > mind for a while as I have been working on this: > > http://lukearno.com/projects/selector/ > > I think dispatching is best left as an (obvious) exercise > to the reader. What dispatching makes sense, what > metaphor or technique should be applied, is situational. I don't think the idea is obvious to readers. Prefix dispatching is also unique, in that it's the only kind of dispatching that can be represented fully in conventional WSGI (without other environ keys); though host matching also pretty much works. Prefix matching also doesn't compete very actively with other dispatching techniques. It's not enough to build a framework on, it represents a technique that already exists in lots of web servers > When I see other WSGI servers requiring a list of > prefix/app pairs in their init signature, I am put off. > > The server's job is to translate HTTP (or SCGI, FCGI, > etc.) to WSGI. Just do that. This isn't being proposed as part of the server, just as a tool in wsgiref. It's up to the user to use the dispatcher together with the server. It's part of other servers, > To me WSGI is not just the freedom of frameworks > interoperating, but the freedom _from_ frameworks. > The stack can be unbundled and I can pick the the > best thing for my needs at each layer, ? la carte. This is still unbundled. I think that including an unbundled dispatcher actually can help encourage more unbundled dispatchers outside of the standard library. Without a prefix dispatcher available and easily referenced in the documentation, I think people will see wsgiref as incomplete and silly, because it's ingrained in people that the web server does dispatching. Another problem is if they don't use WSGI/CGI conventions for what prefix dispatching implement on their own, which means that they won't be as compatible with other webservers and environments. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From luke.arno at gmail.com Tue May 2 22:54:44 2006 From: luke.arno at gmail.com (Luke Arno) Date: Tue, 2 May 2006 16:54:44 -0400 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <4457808F.2030403@colorstudy.com> References: <44527506.2070407@colorstudy.com> <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com> <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com> <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com> <5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com> <445409DD.2090304@colorstudy.com> <4457808F.2030403@colorstudy.com> Message-ID: On 5/2/06, Ian Bicking wrote: > Luke Arno wrote: > > I don't pipe up much but dispatch has been on my > > mind for a while as I have been working on this: > > > > http://lukearno.com/projects/selector/ > > > > I think dispatching is best left as an (obvious) exercise > > to the reader. What dispatching makes sense, what > > metaphor or technique should be applied, is situational. > > I don't think the idea is obvious to readers. Prefix dispatching is > also unique, in that it's the only kind of dispatching that can be > represented fully in conventional WSGI (without other environ keys); > though host matching also pretty much works. > I think it is obvious. I can't count the number of times I have seen a novice web developer create a "master" PHP script to push his/her whole application through in an effort to take over dispatch. I think that it is the most natural thing to do. > Prefix matching also doesn't compete very actively with other > dispatching techniques. It's not enough to build a framework on, it > represents a technique that already exists in lots of web servers > I am not concerned with competition but with clarity. Including this in the code could be interpreted as saying "this is how dispatching is done with WSGI." The right message, from my perspective is "dispatching is not part of WSGI." I think some intelligent mention of the issue of dispatch in the docs would be more constructive than a lame default. Maybe dispatch could be demonstrated in the docs rather than actually included in the code base? > > > When I see other WSGI servers requiring a list of > > prefix/app pairs in their init signature, I am put off. > > > > The server's job is to translate HTTP (or SCGI, FCGI, > > etc.) to WSGI. Just do that. > > This isn't being proposed as part of the server, just as a tool in > wsgiref. It's up to the user to use the dispatcher together with the > server. It's part of other servers, > Still. It seems crufty and potentially misleading. > > To me WSGI is not just the freedom of frameworks > > interoperating, but the freedom _from_ frameworks. > > The stack can be unbundled and I can pick the the > > best thing for my needs at each layer, ? la carte. > > This is still unbundled. It is a looser bundle but a bundle still. > I think that including an unbundled dispatcher > actually can help encourage more unbundled dispatchers outside of the > standard library. I am not sure how. Instead of creating their own and learning, users may be trying to kluge around what they feel like they are "supposed" to be using. > > Without a prefix dispatcher available and easily referenced in the > documentation, I think people will see wsgiref as incomplete and silly, > because it's ingrained in people that the web server does dispatching. > Another problem is if they don't use WSGI/CGI conventions for what > prefix dispatching implement on their own, which means that they won't > be as compatible with other webservers and environments. > As you say, the idea of dispatch is already ingrained, so the need _will_ be obvious. ;) I don't see how the user could miss that they need to do dispatch somehow (especially if it says so right in the docs). Not providing a lame default invites them to think a little about how _they_ want to do it. Daniel Boorstin said: "The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge." Users _do_ expect a framework to provide dispatching capability, of course. But this is a server not a framework. No one should think it is "silly" or "incomplete" for not doing more than its job. Finally, I think our disagreement is rather small for all this text. All I am trying to say is that I think an example in the docs would be much more useful than an implementation included in the code, in this case. Either way, I am happy that we will have the server in the standard lib. Whatever Phillip decides to do is fine with me. Cheers, - Luke From titus at caltech.edu Thu May 4 08:54:38 2006 From: titus at caltech.edu (Titus Brown) Date: Wed, 3 May 2006 23:54:38 -0700 Subject: [Web-SIG] wsgiref problems & quibbles Message-ID: <20060504065438.GA9574@caltech.edu> Hi, Phillip, so I threw together a few WSGI apps recently, and used wsgiref to serve them. I ran into two problems, and had a few quibbles to raise as well. === First, a patch to fix the existing unit tests is attached. === Second, there's a bug in handlers.BaseHandler.finish_response, line 132. The line: if not self.result_is_file() and not self.sendfile(): should read if not self.result_is_file() or not self.sendfile(): ^^ Otherwise use of wsgi.file_wrapper fails to return any data. I also can't find any place in the code where 'sendfile' is called to actually send the file. Should that 'if' statement have an 'else'?? Patch attached, along with 'break-wsgiref.py'. === And now for the few miscellaneous quibbles ;), mostly in re WSGIServer: * the __init__ function is inherited, ultimately, from SocketServer.TCPServer via BaseHTTPServer. This gives it three uglification problems: - the host, port are passed in as a tuple; - the request handler must be explicitly specified; - the WSGI app object must be set elsewhere. i.e. to instantiate WSGIServer and set it up, you need to call s = wsgiref.simple_server.WSGIServer((host, port), wsgiref.simple_server.RequestHandler) s.set_app(app) This seems *very* counterintuitive and overcomplex to me, and it seems to be entirely for the benefit of complying with an interface inherited from code that WSGI newbies probably won't be using anyway. My suggestion is to eliminate this complexity and simply make it s = wsgiref.WSGIServer(host, port, app) or (if you still insist on the performance enhancement of keeping it under a separate module ;) s = wsgiref.simple_server.WSGIServer(host, port, app) What do you think? * the get_app/set_app functions must be due to support for python 2.1; they're obviously unnecessary now, what with properties in 2.2 and up. Should they be changed to properties, for inclusion in the stdlib? * the simple_server code is completely untested by the unit tests, it seems. Do you have any thoughts on how to instrument it to be tested? (The easiest way for me to test it would be to install wsgi_intercept and use urllib2 to run various mock HTTP tests. I doubt people want wsgi_intercept in the stdlib, tho, even if it's only used for tests...) * finally, there are a lot of blank lines loitering about in your python files. Some of them are for code spacing, some of them are just hanging out at the bottom of files like simple_server.py. Do you want to leave these in? Apologies for the minor quibbles, but I'm trying to take the chance to go over the module *before* it becomes (more or less) fixed in stone...! cheers, --titus -------------- next part -------------- Index: src/wsgiref/tests/test_handlers.py =================================================================== --- src/wsgiref/tests/test_handlers.py (revision 2131) +++ src/wsgiref/tests/test_handlers.py (working copy) @@ -170,7 +170,7 @@ stdpat = ( r"HTTP/%s 200 OK\r\n" - r"Date: \w{3} \w{3} [ 0123]\d \d\d:\d\d:\d\d \d{4}\r\n" + r"Date: \w{3}, \d\d \w{3} \d{4} \d\d:\d\d:\d\d \w{3}\r\n" r"%s" r"Content-Length: 0\r\n" r"\r\n" ) shortpat = ( @@ -203,6 +203,7 @@ (stdpat%(version,sw), h.stdout.getvalue()) ) + TestClasses = ( HandlerTests, ) Index: src/wsgiref/handlers.py =================================================================== --- src/wsgiref/handlers.py (revision 2131) +++ src/wsgiref/handlers.py (working copy) @@ -129,7 +129,7 @@ in the event loop to iterate over the data, and to call 'self.close()' once the response is finished. """ - if not self.result_is_file() and not self.sendfile(): + if not self.result_is_file() or not self.sendfile(): for data in self.result: self.write(data) self.finish_content() -------------- next part -------------- A non-text attachment was scrubbed... Name: break-wsgiref.py Type: text/x-python Size: 643 bytes Desc: not available Url : http://mail.python.org/pipermail/web-sig/attachments/20060503/fe753e4d/attachment.py From ianb at colorstudy.com Fri May 5 00:04:08 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 04 May 2006 17:04:08 -0500 Subject: [Web-SIG] wsgiref problems & quibbles In-Reply-To: <20060504065438.GA9574@caltech.edu> References: <20060504065438.GA9574@caltech.edu> Message-ID: <445A7A58.3080304@colorstudy.com> Titus Brown wrote: > or (if you still insist on the performance enhancement of > keeping it under a separate module ;) > > s = wsgiref.simple_server.WSGIServer(host, port, app) Shouldn't that be wsgiref.simpleserver, to make it fit PEP 8? -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From titus at caltech.edu Fri May 19 02:27:07 2006 From: titus at caltech.edu (Titus Brown) Date: Thu, 18 May 2006 17:27:07 -0700 Subject: [Web-SIG] 'scotch' WSGI recording & proxy. Message-ID: <20060519002707.GA16477@caltech.edu> Hi folks, here's a project I've been working on: http://issola.caltech.edu/~t/scotch/doc/ 'scotch' currently consists of two modules, WSGI recording middleware and a WSGI proxy application. See the docs above for some minimal information. You can grab it via darcs at darcs.idyll.org/~t/projects/scotch/ or in a tarball at http://darcs.idyll.org/~t/projects/scotch-latest.tar.gz I posted a long blithering blog entry about this today here: http://www.advogato.org/person/titus/diary.html?start=177 (at the bottom). I'm interested in comments, thoughts, criticisms, etc... right now it's rather immature, and I'm hoping to get some insight into where it should go from your comments. cheers, --titus From pje at telecommunity.com Mon May 22 21:33:00 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 22 May 2006 15:33:00 -0400 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <44526DD3.4010807@colorstudy.com> References: Message-ID: <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >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 Ian, I see this is under the MIT license. Do you also have a PSF contributor agreement (to license under AFL/ASF)? If not, can you place a copy of this under a compatible license so that I can add this to the version of wsgiref that gets checked into the stdlib? (And if any PSF folks can chime in with easier ways to handle this, please do.) From ianb at colorstudy.com Tue May 23 06:23:01 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 22 May 2006 23:23:01 -0500 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> References: <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> Message-ID: <44728E25.60807@colorstudy.com> Phillip J. Eby wrote: > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> 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 > > Ian, I see this is under the MIT license. Do you also have a PSF > contributor agreement (to license under AFL/ASF)? If not, can you place > a copy of this under a compatible license so that I can add this to the > version of wsgiref that gets checked into the stdlib? I don't have a contributor agreement. I can change the license in place, or sign an agreement, or whatever; someone should just tell me what to do. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From guido at python.org Tue May 23 06:25:30 2006 From: guido at python.org (Guido van Rossum) Date: Mon, 22 May 2006 21:25:30 -0700 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <44728E25.60807@colorstudy.com> References: <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> <44728E25.60807@colorstudy.com> Message-ID: This explains what to do, and which license to use: http://www.python.org/psf/contrib/ --Guido On 5/22/06, Ian Bicking wrote: > Phillip J. Eby wrote: > > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: > >> 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 > > > > Ian, I see this is under the MIT license. Do you also have a PSF > > contributor agreement (to license under AFL/ASF)? If not, can you place > > a copy of this under a compatible license so that I can add this to the > > version of wsgiref that gets checked into the stdlib? > > I don't have a contributor agreement. I can change the license in > place, or sign an agreement, or whatever; someone should just tell me > what to do. > > > -- > Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From pje at telecommunity.com Tue May 23 08:01:20 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 23 May 2006 02:01:20 -0400 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: References: <44728E25.60807@colorstudy.com> <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> <44728E25.60807@colorstudy.com> Message-ID: <5.1.1.6.0.20060523015956.01f5efd8@mail.telecommunity.com> It's not clear to me whether this means that Ian can just relicense his code for me to slap into wsgiref and thence into Python by virtue of my own PSF contribution form and the compatible license, or whether it means Ian has to sign a form too. At 09:25 PM 5/22/2006 -0700, Guido van Rossum wrote: >This explains what to do, and which license to use: > >http://www.python.org/psf/contrib/ > >--Guido > >On 5/22/06, Ian Bicking wrote: >>Phillip J. Eby wrote: >> > At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> >> 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 >> > >> > Ian, I see this is under the MIT license. Do you also have a PSF >> > contributor agreement (to license under AFL/ASF)? If not, can you place >> > a copy of this under a compatible license so that I can add this to the >> > version of wsgiref that gets checked into the stdlib? >> >>I don't have a contributor agreement. I can change the license in >>place, or sign an agreement, or whatever; someone should just tell me >>what to do. >> >> >>-- >>Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org >>_______________________________________________ >>Python-Dev mailing list >>Python-Dev at python.org >>http://mail.python.org/mailman/listinfo/python-dev >>Unsubscribe: >>http://mail.python.org/mailman/options/python-dev/guido%40python.org > > >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) From ianb at colorstudy.com Wed May 24 22:25:08 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 24 May 2006 15:25:08 -0500 Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib In-Reply-To: <44728E25.60807@colorstudy.com> References: <5.1.1.6.0.20060522153116.03ea4468@mail.telecommunity.com> <44728E25.60807@colorstudy.com> Message-ID: <4474C124.3030507@colorstudy.com> Ian Bicking wrote: > Phillip J. Eby wrote: > >>At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> >>>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 >> >>Ian, I see this is under the MIT license. Do you also have a PSF >>contributor agreement (to license under AFL/ASF)? If not, can you place >>a copy of this under a compatible license so that I can add this to the >>version of wsgiref that gets checked into the stdlib? > > > I don't have a contributor agreement. I can change the license in > place, or sign an agreement, or whatever; someone should just tell me > what to do. I faxed in a contributor aggreement, and added this to the comment header of the file: # Also licenced under the Apache License, 2.0: http://opensource.org/licenses/apache2.0.php # Licensed to PSF under a Contributor Agreement From t.koutsovassilis at innoscript.org Fri May 26 00:30:26 2006 From: t.koutsovassilis at innoscript.org (Tassos Koutsovassilis) Date: Fri, 26 May 2006 01:30:26 +0300 Subject: [Web-SIG] Quill 0.1-alpha1 released Message-ID: <000001c680e7$d9458350$6400a8c0@porc2> It took us quite longer than we expected but here it is. Quill is a visual Web interface designer based on QuiX, Porcupine's integrated XML User-Interface Language. We believe this is a major leap for the web interface design process, as it has become almost identical to this of a common desktop application. This is an alpha release and as such there are a lot of missing features, but generally you can get things done a lot faster and easier than before. This release supports almost every QuiX widget, giving you full control over it, exhibiting all of its editable properties. Have you ever thought that you could have a QuiX window with a menu bar and a tool bar deployed in less than 3 minutes? Watch this screencast to see how this is achieved with Quill and Porcupine: http://www.innoscript.org/screencasts/demo1.swf.html Quill runs on Linux and Windows and it is provided as freeware. Tassos Koutsovassilis http://www.innoscript.org From stephan.diehl at gmx.net Mon May 29 12:35:28 2006 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Mon, 29 May 2006 12:35:28 +0200 Subject: [Web-SIG] wsgi.org domain Message-ID: <200605291235.28205.stephan.diehl@gmx.net> Hi folks, I'm happy to be able to announce that we now have a wsgi.org domain. Last week, while learning/researching wsgi a bit, I wished for a central place to find wsgi related documentation and links. (For some reason, wiki.python.org never comes to my mind when researching things, go figure) wsgi.org was not taken and Ian and Philip didn't show any interest in running such a site. At the moment, you'll just see 1. a simple homepage at www.wsgi.org and 2. a wiki at wiki.wsgi.org Setting up the site took (of course) much longer than expected, so I just managed to fill in some usefull links to existing documentation. There are no restrictions with the wiki other than the need to register before writing/editing. Please feel free to write articles. Contact me, if you have other ideas what to run on this server (maybe a subversion repository?, a wsgi testbed?) Cheers and happy writing Stephan From ianb at colorstudy.com Tue May 30 18:14:41 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 30 May 2006 11:14:41 -0500 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <200605291235.28205.stephan.diehl@gmx.net> References: <200605291235.28205.stephan.diehl@gmx.net> Message-ID: <447C6F71.7000906@colorstudy.com> Stephan Diehl wrote: > Hi folks, > > I'm happy to be able to announce that we now have a wsgi.org domain. > Last week, while learning/researching wsgi a bit, I wished for a central place > to find wsgi related documentation and links. (For some reason, > wiki.python.org never comes to my mind when researching things, go figure) > wsgi.org was not taken and Ian and Philip didn't show any interest in running > such a site. > At the moment, you'll just see > 1. a simple homepage at www.wsgi.org and > 2. a wiki at wiki.wsgi.org Thanks for setting this up. Could the wiki just be the front page? Would there be any way to fit feeds into the page too? I'd be interested in setting up a wsgi feed from the Cheese Shop (using the category or keywords somehow). Hrm... now I'm not sure where they are doing that; maybe in their toolbox. Anyway, if wsgi.org can consume it, I can try to build the feed. > Setting up the site took (of course) much longer than expected, so I just > managed to fill in some usefull links to existing documentation. > There are no restrictions with the wiki other than the need to register before > writing/editing. I'll try to put in some links in the next couple days. Should we try to move http://wiki.python.org/moin/WSGIImplementations over to this site, or just copy it, or...? Maybe as content from python.org wiki pages gets integrated, we should just put prominent links on those pages to wsgi.org. I'm figuring the basic layout should be: What is WSGI: - spec - tutorials and articles What uses WSGI: - servers - applications - frameworks - middleware, webish tools - testing I'm not sure where non-English content should go; you have a German link, and I've seen content in other languages as well. Would it be best to have a page for each other language, with all the available languages linked off the front page? From stephan.diehl at gmx.net Tue May 30 20:43:49 2006 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Tue, 30 May 2006 20:43:49 +0200 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <447C6F71.7000906@colorstudy.com> References: <200605291235.28205.stephan.diehl@gmx.net> <447C6F71.7000906@colorstudy.com> Message-ID: <200605302043.49867.stephan.diehl@gmx.net> On Tuesday 30 May 2006 18:14, Ian Bicking wrote: > Stephan Diehl wrote: [...] > > Thanks for setting this up. Could the wiki just be the front page? This can be set up any way we like. It's actually a hosted virtual linux server. My personal taste is not to have a wiki a the front. > Would there be any way to fit feeds into the page too? I'd be > interested in setting up a wsgi feed from the Cheese Shop (using the > category or keywords somehow). Hrm... now I'm not sure where they are > doing that; maybe in their toolbox. Anyway, if wsgi.org can consume it, > I can try to build the feed. Sound like some application server like Webware, Cheerypy or Pylons (or any other of the existing python web frameworks :-) ) In the long run, I'd propose to use Pylons (or any other WSGI base framework), but I'm much more comfortable with Webware or Cheerypy for a quick'n dirty setup. > [...] > > I'll try to put in some links in the next couple days. Should we try to > move http://wiki.python.org/moin/WSGIImplementations over to this site, > or just copy it, or...? Maybe as content from python.org wiki pages > gets integrated, we should just put prominent links on those pages to > wsgi.org. sounds like a plan. > > I'm figuring the basic layout should be: > > What is WSGI: > - spec > - tutorials and articles > > What uses WSGI: > - servers > - applications > - frameworks > - middleware, webish tools > - testing > > I'm not sure where non-English content should go; you have a German > link, and I've seen content in other languages as well. Would it be > best to have a page for each other language, with all the available > languages linked off the front page? to start with english content is fine as it's safe to assume that a serious python developer has at least a basic understanding of german. I'd be happy to give you (or any other trustworthy person) direct access to set things up. Just mail me your ssh key. I've asked a designer friend to help out with the design, so we might have a good looking site after a while... Cheers Stephan From ianb at colorstudy.com Tue May 30 23:50:30 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 30 May 2006 16:50:30 -0500 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <200605302043.49867.stephan.diehl@gmx.net> References: <200605291235.28205.stephan.diehl@gmx.net> <447C6F71.7000906@colorstudy.com> <200605302043.49867.stephan.diehl@gmx.net> Message-ID: <447CBE26.4020301@colorstudy.com> Stephan Diehl wrote: > On Tuesday 30 May 2006 18:14, Ian Bicking wrote: > >>Stephan Diehl wrote: > > [...] > > >>Thanks for setting this up. Could the wiki just be the front page? > > > This can be set up any way we like. It's actually a hosted virtual linux > server. My personal taste is not to have a wiki a the front. I don't really like Wikis as public pages that much either, but they do make collaboration easy. Maybe there could be a wiki backend with a non-wiki frontend? Then we can work on the content through the web, but present a static-looking site to the world. There can still be wiki artifacts, but in part we can just avoid that editorially. E.g., take out the special icon for off-site links, and avoid using WikiWords, then wrap the wiki content up in a nice template. >>Would there be any way to fit feeds into the page too? I'd be >>interested in setting up a wsgi feed from the Cheese Shop (using the >>category or keywords somehow). Hrm... now I'm not sure where they are >>doing that; maybe in their toolbox. Anyway, if wsgi.org can consume it, >>I can try to build the feed. > > > Sound like some application server like Webware, Cheerypy or Pylons (or any > other of the existing python web frameworks :-) ) > In the long run, I'd propose to use Pylons (or any other WSGI base framework), > but I'm much more comfortable with Webware or Cheerypy for a quick'n dirty > setup. I was thinking wsgi.org would mostly be content, so I don't know if anything special is needed. The RSSReader.py macro (listed here: http://moinmoin.wikiwikiweb.de/MacroMarket) looks like it could handle a feed. From todd at slack.net Wed May 31 01:18:13 2006 From: todd at slack.net (Todd Grimason) Date: Tue, 30 May 2006 19:18:13 -0400 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <200605302043.49867.stephan.diehl@gmx.net> References: <200605291235.28205.stephan.diehl@gmx.net> <447C6F71.7000906@colorstudy.com> <200605302043.49867.stephan.diehl@gmx.net> Message-ID: <20060530231813.GA9609@detroit.slack.net> * Stephan Diehl [2006-05-30 14:44]: > to start with english content is fine as it's safe to assume that a serious > python developer has at least a basic understanding of german. > Waaait a minute. My Beginning Python book never said anything about having to learn German as well! Dutch maybe, but German too? Sheesh! -- ________________________________ toddgrimason*todd[ at ]slack.net From stephan.diehl at gmx.net Wed May 31 08:35:26 2006 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Wed, 31 May 2006 08:35:26 +0200 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <20060530231813.GA9609@detroit.slack.net> References: <200605291235.28205.stephan.diehl@gmx.net> <200605302043.49867.stephan.diehl@gmx.net> <20060530231813.GA9609@detroit.slack.net> Message-ID: <200605310835.26683.stephan.diehl@gmx.net> On Wednesday 31 May 2006 01:18, you wrote: > * Stephan Diehl [2006-05-30 14:44]: > > to start with english content is fine as it's safe to assume that a > > serious python developer has at least a basic understanding of german. > > Waaait a minute. My Beginning Python book never said anything about > having to learn German as well! Dutch maybe, but German too? Sheesh! argghhh, duck away. sorry about that. Of course s/german/english :-) From stephan.diehl at gmx.net Wed May 31 09:32:11 2006 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Wed, 31 May 2006 09:32:11 +0200 Subject: [Web-SIG] wsgi.org domain In-Reply-To: <447CBE26.4020301@colorstudy.com> References: <200605291235.28205.stephan.diehl@gmx.net> <200605302043.49867.stephan.diehl@gmx.net> <447CBE26.4020301@colorstudy.com> Message-ID: <200605310932.11090.stephan.diehl@gmx.net> On Tuesday 30 May 2006 23:50, Ian Bicking wrote: > Stephan Diehl wrote: [...] > > I don't really like Wikis as public pages that much either, but they do > make collaboration easy. Maybe there could be a wiki backend with a > non-wiki frontend? Then we can work on the content through the web, but > present a static-looking site to the world. There can still be wiki > artifacts, but in part we can just avoid that editorially. E.g., take > out the special icon for off-site links, and avoid using WikiWords, then > wrap the wiki content up in a nice template. the wiki is now the homepage. for the time being, the current setup is all right. > [...] > > I was thinking wsgi.org would mostly be content, so I don't know if > anything special is needed. The RSSReader.py macro (listed here: > http://moinmoin.wikiwikiweb.de/MacroMarket) looks like it could handle a > feed. Know thy tools :) The RSSReader.py macro just works. At the moment, the full cheeseshop feed is shown. It would be nice if the the cheeseshop feed would contain category information (hint, hint...) so one could filter on that.