<?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 for Catamorphic Labs</title>
	<atom:link href="http://catamorphiclabs.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://catamorphiclabs.com</link>
	<description>Emerging Technologies, in the palm of your hand</description>
	<pubDate>Wed, 10 Mar 2010 22:15:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Data Processing with Ruby, AMQP and RabbitMQ by john</title>
		<link>http://catamorphiclabs.com/2009/04/18/data-processing-with-ruby-amqp-and-rabbitmq/comment-page-1/#comment-3</link>
		<dc:creator>john</dc:creator>
		<pubDate>Wed, 22 Apr 2009 17:34:39 +0000</pubDate>
		<guid isPermaLink="false">http://catamorphiclabs.com/?p=4#comment-3</guid>
		<description>XMPP was considered as an option but did not fit into the problem domain as cleanly as AMQP.  What we really needed was a persistent/recoverable notification system of legacy data needing to be processed.  In this case it was drilled down to individual records.  To do this in XMPP we would need a way to communicate that a record was processed which would require a middleman or the publisher of the legacy data to receive back replies that a job was finished.  Another downpoint of XMPP in this problem domain is the ability to add workers and publishers dynamically.  In XMPP this would require some sort of communication bridge that would allow publishers to see appropriate workers and then load balance between them.  With RabbitMQ this was already built-in which allowed us to develop the new system more quickly.  AMQP and RabbitMQ were chosen over XMPP due to their features and the specific problem domain.</description>
		<content:encoded><![CDATA[<p>XMPP was considered as an option but did not fit into the problem domain as cleanly as AMQP.  What we really needed was a persistent/recoverable notification system of legacy data needing to be processed.  In this case it was drilled down to individual records.  To do this in XMPP we would need a way to communicate that a record was processed which would require a middleman or the publisher of the legacy data to receive back replies that a job was finished.  Another downpoint of XMPP in this problem domain is the ability to add workers and publishers dynamically.  In XMPP this would require some sort of communication bridge that would allow publishers to see appropriate workers and then load balance between them.  With RabbitMQ this was already built-in which allowed us to develop the new system more quickly.  AMQP and RabbitMQ were chosen over XMPP due to their features and the specific problem domain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Data Processing with Ruby, AMQP and RabbitMQ by bmuller</title>
		<link>http://catamorphiclabs.com/2009/04/18/data-processing-with-ruby-amqp-and-rabbitmq/comment-page-1/#comment-2</link>
		<dc:creator>bmuller</dc:creator>
		<pubDate>Wed, 22 Apr 2009 14:44:50 +0000</pubDate>
		<guid isPermaLink="false">http://catamorphiclabs.com/?p=4#comment-2</guid>
		<description>Why AMQP instead of XMPP?</description>
		<content:encoded><![CDATA[<p>Why AMQP instead of XMPP?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
