<?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: Protocol Buffers: deja yawn</title>
	<atom:link href="http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/</link>
	<description>pushing soa up the slope (with a pointy stick)</description>
	<lastBuildDate>Wed, 04 Aug 2010 15:33:11 -0700</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Saul Caganoff</title>
		<link>http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/comment-page-1/#comment-34</link>
		<dc:creator>Saul Caganoff</dc:creator>
		<pubDate>Tue, 15 Jul 2008 05:46:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/#comment-34</guid>
		<description>Great comments David and point taken with the embedded systems requirements. 

I guess the question is whether Google are aiming at embedded systems or enterprise systems. My point is that the enterprise systems space is already crowded with protocols to the point of confusion. 

Embedded systems and ubiquitous computing is a whole &#039;nother area.</description>
		<content:encoded><![CDATA[<p>Great comments David and point taken with the embedded systems requirements. </p>
<p>I guess the question is whether Google are aiming at embedded systems or enterprise systems. My point is that the enterprise systems space is already crowded with protocols to the point of confusion. </p>
<p>Embedded systems and ubiquitous computing is a whole &#8216;nother area.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Ryan</title>
		<link>http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/comment-page-1/#comment-33</link>
		<dc:creator>David Ryan</dc:creator>
		<pubDate>Tue, 15 Jul 2008 04:40:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.soabloke.com/2008/07/15/protocol-buffers-deja-yawn/#comment-33</guid>
		<description>OK, I&#039;ll bite.  You ask &quot;why do you want yet another binary encoding format?&quot;

To a large extent this conversation spanning these blogs is related to enterprise systems, however, the requirement for communications is much wider than this.  There&#039;s a huge gap in the tools and technology to deal with the emerging smart devices.  Look at the ZigBee technology stack, HomePlug, or other emerging transports.  The need binary communication protocols and the best we&#039;ve got is a handfull of ASN.1, XDR, etc.

Obviously if Google are developing this solution they&#039;re not happy with all the current solutions out there now.  All these so called experts have decided that what is available solves all the problems.  They don&#039;t.  More research and experimentation is required.  The best way to do this is release things like Protocol Buffers and let the world that see a need in these to innovate and improve on them.

And Yes, if you look at the link I posted, you&#039;ll see that I&#039;m another developer of alternative binary encoding formats.  It does a job that Protocol Buffers, ASN.1,XDR, etc don&#039;t do which is why I&#039;m interested in researching it.  The fact is that many of the concepts of loose coupling that is found in XML can be applied to binary using the right encoding formats.  This is the area my format Argot is exploring.

We will need more encoding formats until we have a set that is as flexible and as well endorsed as TCP/IP is for transport.  We are no-where near that point now.  Yes, we don&#039;t just need one more encoding formats, we need a whole lot more encoding formats.  We need to let them breed and watch them evolve into the fittest for the job.  Right now, all I see if everyone try and shoot anything new that appears saying that its a &quot;not invented here&quot; syndrome or other such.  The fact is, there&#039;s so few solutions in this space that business need to develop these new protocols to fill the huge gaps that exist.

Rant over.</description>
		<content:encoded><![CDATA[<p>OK, I&#8217;ll bite.  You ask &#8220;why do you want yet another binary encoding format?&#8221;</p>
<p>To a large extent this conversation spanning these blogs is related to enterprise systems, however, the requirement for communications is much wider than this.  There&#8217;s a huge gap in the tools and technology to deal with the emerging smart devices.  Look at the ZigBee technology stack, HomePlug, or other emerging transports.  The need binary communication protocols and the best we&#8217;ve got is a handfull of ASN.1, XDR, etc.</p>
<p>Obviously if Google are developing this solution they&#8217;re not happy with all the current solutions out there now.  All these so called experts have decided that what is available solves all the problems.  They don&#8217;t.  More research and experimentation is required.  The best way to do this is release things like Protocol Buffers and let the world that see a need in these to innovate and improve on them.</p>
<p>And Yes, if you look at the link I posted, you&#8217;ll see that I&#8217;m another developer of alternative binary encoding formats.  It does a job that Protocol Buffers, ASN.1,XDR, etc don&#8217;t do which is why I&#8217;m interested in researching it.  The fact is that many of the concepts of loose coupling that is found in XML can be applied to binary using the right encoding formats.  This is the area my format Argot is exploring.</p>
<p>We will need more encoding formats until we have a set that is as flexible and as well endorsed as TCP/IP is for transport.  We are no-where near that point now.  Yes, we don&#8217;t just need one more encoding formats, we need a whole lot more encoding formats.  We need to let them breed and watch them evolve into the fittest for the job.  Right now, all I see if everyone try and shoot anything new that appears saying that its a &#8220;not invented here&#8221; syndrome or other such.  The fact is, there&#8217;s so few solutions in this space that business need to develop these new protocols to fill the huge gaps that exist.</p>
<p>Rant over.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
