<?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: WOA and &quot;Application Neutrality&quot;</title>
	<atom:link href="http://www.subbu.org/blog/2008/11/woa-and-application-neutrality/feed" rel="self" type="application/rss+xml" />
	<link>http://www.subbu.org/blog/2008/11/woa-and-application-neutrality</link>
	<description>HTTP, REST and some Cycling</description>
	<lastBuildDate>Mon, 15 Mar 2010 08:14:09 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mark</title>
		<link>http://www.subbu.org/blog/2008/11/woa-and-application-neutrality/comment-page-1#comment-17787</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Thu, 29 Jan 2009 10:39:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.subbu.org/?p=665#comment-17787</guid>
		<description>Fantastic set of blogs Subbu.  Thanks.
I read the list thread and while not a specialist I wasn&#039;t convinced by the &#039;application neutrality&#039; idea. 

Something not mentioned was the idea that the Content-Type could usefully be:
extensible (i.e. built-in forward/backward compatibility), self-delimiting (one or several messages) and self-describing.  
This wouldn&#039;t make your RESTful service/site/application of less application-neutral/generic. But, assuming the clients know how to consume such content, wouldn&#039;t it make the content more robust to the server side changing (within some limits) the content encoded while the client consumer doesn&#039;t change.
Protocol buffers fails the self-describing, since if I understand correctly the client has to be given the .proto file. As far as I&#039;ve encountered it seems that extprot is all there is (http://eigenclass.org/R2/writings/extprot-extensible-protocols-intro).

Any thoughts on its suitability as a preferred Content-Type, cf XML and any other type?

Cheers
Mark</description>
		<content:encoded><![CDATA[<p>Fantastic set of blogs Subbu.  Thanks.<br />
I read the list thread and while not a specialist I wasn&#8217;t convinced by the &#8216;application neutrality&#8217; idea. </p>
<p>Something not mentioned was the idea that the Content-Type could usefully be:<br />
extensible (i.e. built-in forward/backward compatibility), self-delimiting (one or several messages) and self-describing.<br />
This wouldn&#8217;t make your RESTful service/site/application of less application-neutral/generic. But, assuming the clients know how to consume such content, wouldn&#8217;t it make the content more robust to the server side changing (within some limits) the content encoded while the client consumer doesn&#8217;t change.<br />
Protocol buffers fails the self-describing, since if I understand correctly the client has to be given the .proto file. As far as I&#8217;ve encountered it seems that extprot is all there is (<a href="http://eigenclass.org/R2/writings/extprot-extensible-protocols-intro)" rel="nofollow">http://eigenclass.org/R2/writings/extprot-extensible-protocols-intro)</a>.</p>
<p>Any thoughts on its suitability as a preferred Content-Type, cf XML and any other type?</p>
<p>Cheers<br />
Mark</p>
]]></content:encoded>
	</item>
</channel>
</rss>
