<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: WSGI Middleare is cool</title>
	<atom:link href="http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/feed/" rel="self" type="application/rss+xml" />
	<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/</link>
	<description>Thinking about programming in new ways</description>
	<lastBuildDate>Wed, 28 Jul 2010 19:00:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Mark Ramm</title>
		<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/#comment-251634</link>
		<dc:creator>Mark Ramm</dc:creator>
		<pubDate>Sat, 18 Oct 2008 19:18:12 +0000</pubDate>
		<guid isPermaLink="false">http://compoundthinking.com/blog/?p=466#comment-251634</guid>
		<description>Well, the character encoding thing is a problem, as is the fact that you can&#039;t tell the difference between a urlencoded slash and a plain old /.

But I agree that having better dependency management and installation tools is critical for the kind of world of reusable components that I think we should be fostering.  And this is exactly what linux distributions are good at -- they gather hundreds of packages with lots of different versions test them, and make them work together well. dpkg, and other formats have proved themselves in that world, but eggs and the current sdist format have not lived up to that standard in python world. 

Hopefully there&#039;s enough energy on that subject at the moment so that things get sorted out.   (See my last distutils post).</description>
		<content:encoded><![CDATA[<p>Well, the character encoding thing is a problem, as is the fact that you can&#8217;t tell the difference between a urlencoded slash and a plain old /.</p>
<p>But I agree that having better dependency management and installation tools is critical for the kind of world of reusable components that I think we should be fostering.  And this is exactly what linux distributions are good at &#8212; they gather hundreds of packages with lots of different versions test them, and make them work together well. dpkg, and other formats have proved themselves in that world, but eggs and the current sdist format have not lived up to that standard in python world. </p>
<p>Hopefully there&#8217;s enough energy on that subject at the moment so that things get sorted out.   (See my last distutils post).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Brewer</title>
		<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/#comment-246423</link>
		<dc:creator>Robert Brewer</dc:creator>
		<pubDate>Tue, 07 Oct 2008 23:16:54 +0000</pubDate>
		<guid isPermaLink="false">http://compoundthinking.com/blog/?p=466#comment-246423</guid>
		<description>Not to go too far off your main point, but the similarities between WSGI and CGI are not that onerous. By far the larger problem is packaging--we, the industry as a whole, have a long history of distributing standalone packages, or at worst minimizing them to a handful. Heavy use of WSGI requires a whole set of new techniques to discover, identify, collect, install, version-control (both within and between dependencies), compile, build, configure, and test large numbers of disparate components. And Python&#039;s tools for that are...still maturing.</description>
		<content:encoded><![CDATA[<p>Not to go too far off your main point, but the similarities between WSGI and CGI are not that onerous. By far the larger problem is packaging&#8211;we, the industry as a whole, have a long history of distributing standalone packages, or at worst minimizing them to a handful. Heavy use of WSGI requires a whole set of new techniques to discover, identify, collect, install, version-control (both within and between dependencies), compile, build, configure, and test large numbers of disparate components. And Python&#8217;s tools for that are&#8230;still maturing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Ramm</title>
		<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/#comment-245966</link>
		<dc:creator>Mark Ramm</dc:creator>
		<pubDate>Tue, 07 Oct 2008 03:13:27 +0000</pubDate>
		<guid isPermaLink="false">http://compoundthinking.com/blog/?p=466#comment-245966</guid>
		<description>Pete, 

I know that WSGI isn&#039;t perfect, I think the start_response callable was likely a mistake, as was the total dependence on the CGI spec.   Hopefully we can put together a WSGI 2.0 spec which handles the issues that exist with the current one. 

But, I also think that WebOb makes working with the current WSGI spec a lot easier than it has been in the past, and I&#039;d definitely support moving WebOb into the standard library in the next python version.   I wonder if Guido has considered that...

--Mark</description>
		<content:encoded><![CDATA[<p>Pete, </p>
<p>I know that WSGI isn&#8217;t perfect, I think the start_response callable was likely a mistake, as was the total dependence on the CGI spec.   Hopefully we can put together a WSGI 2.0 spec which handles the issues that exist with the current one. </p>
<p>But, I also think that WebOb makes working with the current WSGI spec a lot easier than it has been in the past, and I&#8217;d definitely support moving WebOb into the standard library in the next python version.   I wonder if Guido has considered that&#8230;</p>
<p>&#8211;Mark</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/#comment-245840</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Mon, 06 Oct 2008 22:16:03 +0000</pubDate>
		<guid isPermaLink="false">http://compoundthinking.com/blog/?p=466#comment-245840</guid>
		<description>As I&#039;ve been saying to anyone who will listen for the last 2 years:

Yes, it&#039;s great that we have a standard, but dear $DIETY, does it have to be this once?

It&#039;s all fine &amp; good to talk about the benefits of reusable WSGI components.  However, as someone trying to *author* such components, or modify existing ones, WSGI sucks.</description>
		<content:encoded><![CDATA[<p>As I&#8217;ve been saying to anyone who will listen for the last 2 years:</p>
<p>Yes, it&#8217;s great that we have a standard, but dear $DIETY, does it have to be this once?</p>
<p>It&#8217;s all fine &amp; good to talk about the benefits of reusable WSGI components.  However, as someone trying to *author* such components, or modify existing ones, WSGI sucks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Felix Schwarz</title>
		<link>http://compoundthinking.com/blog/index.php/2008/10/06/wsgi-middleare-is-cool/#comment-245783</link>
		<dc:creator>Felix Schwarz</dc:creator>
		<pubDate>Mon, 06 Oct 2008 18:48:44 +0000</pubDate>
		<guid isPermaLink="false">http://compoundthinking.com/blog/?p=466#comment-245783</guid>
		<description>I got used to WSGI when I wanted to write CGI scripts that could be run with FastCGI easily (or mod_wsgi). And really, this is very easy with WSGI.

The second thing that bought me into WSGI is that I was able to use Beaker   a homegrown identity framework for TG1 while keeping the all the rest.

So WSGI is no silver bullet but comes handy in a lot of situations.</description>
		<content:encoded><![CDATA[<p>I got used to WSGI when I wanted to write CGI scripts that could be run with FastCGI easily (or mod_wsgi). And really, this is very easy with WSGI.</p>
<p>The second thing that bought me into WSGI is that I was able to use Beaker   a homegrown identity framework for TG1 while keeping the all the rest.</p>
<p>So WSGI is no silver bullet but comes handy in a lot of situations.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
