<?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: Why Rails?</title>
	<atom:link href="http://log.reflectivesurface.com/2004/12/19/why-rails/feed/" rel="self" type="application/rss+xml" />
	<link>http://log.reflectivesurface.com/2004/12/19/why-rails/</link>
	<description>Still powered by a contradiction in terms</description>
	<lastBuildDate>Tue, 03 Feb 2009 20:34:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ronaldo</title>
		<link>http://log.reflectivesurface.com/2004/12/19/why-rails/comment-page-1/#comment-345</link>
		<dc:creator>Ronaldo</dc:creator>
		<pubDate>Mon, 20 Dec 2004 00:34:08 +0000</pubDate>
		<guid isPermaLink="false">http://log.reflectivesurface.com/2004/12/19/why-rails/#comment-345</guid>
		<description>I was referring to the limitations imposed by the image-based environment on deployment in some contexts. I guess I should have explained better. 

The image-based environment is one of the things I value the most about Smalltalk, but it actually makes it difficult to deploy applications in limited hosting, while Ruby, Perl, Python and other dynamic applications can be easily plugged in Apache FastCGI architecture or any other similar deployment scenario.

By the way, that would be a good idea to pursue: create a FastCGI or mod_smalltalk Apache module. With time, it would get included in Linux distributions, and it would make using Smalltalk much more feasible in limited hosting platforms.
</description>
		<content:encoded><![CDATA[<p>I was referring to the limitations imposed by the image-based environment on deployment in some contexts. I guess I should have explained better. </p>
<p>The image-based environment is one of the things I value the most about Smalltalk, but it actually makes it difficult to deploy applications in limited hosting, while Ruby, Perl, Python and other dynamic applications can be easily plugged in Apache FastCGI architecture or any other similar deployment scenario.</p>
<p>By the way, that would be a good idea to pursue: create a FastCGI or mod_smalltalk Apache module. With time, it would get included in Linux distributions, and it would make using Smalltalk much more feasible in limited hosting platforms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Robertson</title>
		<link>http://log.reflectivesurface.com/2004/12/19/why-rails/comment-page-1/#comment-344</link>
		<dc:creator>James Robertson</dc:creator>
		<pubDate>Sun, 19 Dec 2004 19:31:59 +0000</pubDate>
		<guid isPermaLink="false">http://log.reflectivesurface.com/2004/12/19/why-rails/#comment-344</guid>
		<description>You said:

&quot;Ruby is built upon the same principles that attracted me to Smalltalk in first place, and doesnt suffer from the limitations of the latter (limitations in the environment, not in the language itself).&quot;

Could you expand on what you mean by limitations of the environment?</description>
		<content:encoded><![CDATA[<p>You said:</p>
<p>&#8220;Ruby is built upon the same principles that attracted me to Smalltalk in first place, and doesnt suffer from the limitations of the latter (limitations in the environment, not in the language itself).&#8221;</p>
<p>Could you expand on what you mean by limitations of the environment?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
