<?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: Friendfeed&#8217;s Bret Taylor talks XMPP on Gillmor Gang</title>
	<atom:link href="http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/</link>
	<description>TechCrunching the Enterprise</description>
	<lastBuildDate>Sun, 14 Mar 2010 11:17:29 -0700</lastBuildDate>
	
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mason Lee</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-5027</link>
		<dc:creator>Mason Lee</dc:creator>
		<pubDate>Mon, 17 Nov 2008 02:04:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-5027</guid>
		<description>Hi Rob.  Agree with you about &quot;products&quot; being king, but not sure what you mean about XMPP not being more fundamentally &quot;real-time&quot; than HTTP.

True, XMPP does send a lot of presence info, but if there&#039;s a lot of &quot;real time&quot; data aside from that, the presence overhead will be relatively small vs. having to make a new HTTP request for each bit of new data.  Even long-polling HTTP requires a new HTTP request be made for each bit of data.

Steve, Brett.  Love the conversation.

--Mason</description>
		<content:encoded><![CDATA[<p>Hi Rob.  Agree with you about &#8220;products&#8221; being king, but not sure what you mean about XMPP not being more fundamentally &#8220;real-time&#8221; than HTTP.</p>
<p>True, XMPP does send a lot of presence info, but if there&#8217;s a lot of &#8220;real time&#8221; data aside from that, the presence overhead will be relatively small vs. having to make a new HTTP request for each bit of new data.  Even long-polling HTTP requires a new HTTP request be made for each bit of data.</p>
<p>Steve, Brett.  Love the conversation.</p>
<p>&#8211;Mason</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc&#8217;s Voice &#187; Blog Archive &#187; Euphoria subsiding, now its down to business</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-4961</link>
		<dc:creator>Marc&#8217;s Voice &#187; Blog Archive &#187; Euphoria subsiding, now its down to business</dc:creator>
		<pubDate>Fri, 14 Nov 2008 05:50:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-4961</guid>
		<description>[...] I&#8217;m bummed Brett and Steve didn&#8217;t hear me start singing Funkadelics, but I was going off... Maybe next time. [...]</description>
		<content:encoded><![CDATA[<p>[...] I&#8217;m bummed Brett and Steve didn&#8217;t hear me start singing Funkadelics, but I was going off&#8230; Maybe next time. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2008-11-11 &#171; 個人的な雑記</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-4872</link>
		<dc:creator>links for 2008-11-11 &#171; 個人的な雑記</dc:creator>
		<pubDate>Tue, 11 Nov 2008 22:04:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-4872</guid>
		<description>[...] Friendfeed’s Bret Taylor talks XMPP on Gillmor Gang (tags: friendfeed XMPP) [...]</description>
		<content:encoded><![CDATA[<p>[...] Friendfeed’s Bret Taylor talks XMPP on Gillmor Gang (tags: friendfeed XMPP) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Spectre</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-4867</link>
		<dc:creator>Rob Spectre</dc:creator>
		<pubDate>Tue, 11 Nov 2008 05:02:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-4867</guid>
		<description>I really don&#039;t understand what the hell Mark was talking about.  In the babbling that preceded what may have eventually evolved into a question, Mark mentioned that he technically &quot;knew enough to be dangerous.&quot;  I think before the call dropped off that assertion was revealed to be charitable.

XMPP is no more fundamentally engineered to be a &quot;real-time&quot; protocol than HTTP.  The lionshare of Jabber traffic is redundant presence overhead just as the lionshare of web traffic is connection setup and acknowledgement.  The capability of either to satisfy a user need in real-time is dependent completely on its implementation.

A protocol is not a product, and FriendFeed is a product company.  Their continued attention to their products will produce effective software.  Peeling that attention away to work on a protocol might produce effective standards.

But which do you think will satisfy more users or build a stronger company?</description>
		<content:encoded><![CDATA[<p>I really don&#8217;t understand what the hell Mark was talking about.  In the babbling that preceded what may have eventually evolved into a question, Mark mentioned that he technically &#8220;knew enough to be dangerous.&#8221;  I think before the call dropped off that assertion was revealed to be charitable.</p>
<p>XMPP is no more fundamentally engineered to be a &#8220;real-time&#8221; protocol than HTTP.  The lionshare of Jabber traffic is redundant presence overhead just as the lionshare of web traffic is connection setup and acknowledgement.  The capability of either to satisfy a user need in real-time is dependent completely on its implementation.</p>
<p>A protocol is not a product, and FriendFeed is a product company.  Their continued attention to their products will produce effective software.  Peeling that attention away to work on a protocol might produce effective standards.</p>
<p>But which do you think will satisfy more users or build a stronger company?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-4865</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Tue, 11 Nov 2008 04:19:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-4865</guid>
		<description>Friendfeed is running full steam ahead technology, innovation, and feature-wise, twitter appears to be out of steam in those areas.  As long as twitter doesn&#039;t become an albatross around ff&#039;s neck, it could work.

Since friendfeed is a superset of twitter, if ff were to merge with twitter, the entire twitter staff, and much of the technology, would be redundant.</description>
		<content:encoded><![CDATA[<p>Friendfeed is running full steam ahead technology, innovation, and feature-wise, twitter appears to be out of steam in those areas.  As long as twitter doesn&#8217;t become an albatross around ff&#8217;s neck, it could work.</p>
<p>Since friendfeed is a superset of twitter, if ff were to merge with twitter, the entire twitter staff, and much of the technology, would be redundant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Allan</title>
		<link>http://www.techcrunchit.com/2008/11/10/friendfeeds-bret-taylor-talks-xmpp-on-gillmor-gang/comment-page-1/#comment-4863</link>
		<dc:creator>Allan</dc:creator>
		<pubDate>Tue, 11 Nov 2008 04:13:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.techcrunchit.com/?p=714#comment-4863</guid>
		<description>If this economic downturn causes companies to seek M&amp;A options in order to survive, could we see a combination of Twitter and FriendFeed?</description>
		<content:encoded><![CDATA[<p>If this economic downturn causes companies to seek M&amp;A options in order to survive, could we see a combination of Twitter and FriendFeed?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
