<?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: Defending Something Other Than RPC</title>
	<atom:link href="http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/feed/" rel="self" type="application/rss+xml" />
	<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/</link>
	<description>Ask forgiveness, not permission.</description>
	<lastBuildDate>Sat, 19 May 2012 14:32:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: WSOAC#20:Jeff Bezos talks about amazon web services - Service Endpoint</title>
		<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/comment-page-1/#comment-982</link>
		<dc:creator>WSOAC#20:Jeff Bezos talks about amazon web services - Service Endpoint</dc:creator>
		<pubDate>Mon, 09 Jun 2008 17:10:20 +0000</pubDate>
		<guid isPermaLink="false">http://steve.vinoski.net/blog/?p=71#comment-982</guid>
		<description><![CDATA[[...] Vinoski on the need or the lack of creating new frameworks and tools for RPC Burc Oral Gorillazation of SOA, on why SOA need not be as [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Vinoski on the need or the lack of creating new frameworks and tools for RPC Burc Oral Gorillazation of SOA, on why SOA need not be as [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rif Kiamil</title>
		<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/comment-page-1/#comment-981</link>
		<dc:creator>Rif Kiamil</dc:creator>
		<pubDate>Sun, 01 Jun 2008 15:19:50 +0000</pubDate>
		<guid isPermaLink="false">http://steve.vinoski.net/blog/?p=71#comment-981</guid>
		<description><![CDATA[I think should start way back, this new thing is for Cisco Unified Application Environment.. 

How many people here have built a application on it or even know when to select the Cisco Unified Application Environment over the Cisco Unified Customer Respond Solution?

Does anybody know any other products at Cisco that are making use of &quot;Etch&quot;? I know their many products making use of SOAP.

Just my 2great british pennies]]></description>
		<content:encoded><![CDATA[<p>I think should start way back, this new thing is for Cisco Unified Application Environment.. </p>
<p>How many people here have built a application on it or even know when to select the Cisco Unified Application Environment over the Cisco Unified Customer Respond Solution?</p>
<p>Does anybody know any other products at Cisco that are making use of &#8220;Etch&#8221;? I know their many products making use of SOAP.</p>
<p>Just my 2great british pennies</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre Phaneuf</title>
		<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/comment-page-1/#comment-970</link>
		<dc:creator>Pierre Phaneuf</dc:creator>
		<pubDate>Mon, 26 May 2008 14:55:48 +0000</pubDate>
		<guid isPermaLink="false">http://steve.vinoski.net/blog/?p=71#comment-970</guid>
		<description><![CDATA[&quot;I’m very surprised to hear you recommend ICE. How can you support ICE but criticize Etch? These two projects are doing exactly the same thing.&quot;

In my opinion, this is also an excellent reason why they shouldn&#039;t have done Etch: if ICE is exactly the same thing, done by industry experts veterans and well-versed in the previously existing RPC systems, then they shouldn&#039;t have made their own, and used ICE instead.

After all, it is exactly the same!]]></description>
		<content:encoded><![CDATA[<p>&#8220;I’m very surprised to hear you recommend ICE. How can you support ICE but criticize Etch? These two projects are doing exactly the same thing.&#8221;</p>
<p>In my opinion, this is also an excellent reason why they shouldn&#8217;t have done Etch: if ICE is exactly the same thing, done by industry experts veterans and well-versed in the previously existing RPC systems, then they shouldn&#8217;t have made their own, and used ICE instead.</p>
<p>After all, it is exactly the same!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steve</title>
		<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/comment-page-1/#comment-965</link>
		<dc:creator>steve</dc:creator>
		<pubDate>Sun, 25 May 2008 19:43:58 +0000</pubDate>
		<guid isPermaLink="false">http://steve.vinoski.net/blog/?p=71#comment-965</guid>
		<description><![CDATA[@Josh: get to the bottom of what? IMO we&#039;ve already gone through the bottom, and now it just seems that you&#039;re trying to argue with me on new topics just for the sake of arguing. But if you say that&#039;s not true, I&#039;ll give you the benefit of the doubt and try to address your question.

Sure, ICE, like CORBA and other systems, allows access to network-related issues. CORBA does this through exceptions that can come back to the caller from the server side or from the ORB on either side; in a language that supports true exceptions, the application will have to catch them and deal with them. Does that mean these systems are not RPC? I think it&#039;s a gray area that can be argued either way. If you look at the code, it looks just like any local code, so from that point of view, it&#039;s RPC. However, since it&#039;s not necessarily trying to hide network effects and is making the programmer deal with them, then from that point of view, these systems are better in that regard than traditional RPC systems.

HOWEVER, and this is a big however, &lt;em&gt;whether or not these systems conform to some strict definition of RPC is not really the important issue; rather, the main problem is that the RPC-oriented approach in general brings with it a number of problems that go well beyond this&lt;/em&gt;. And I&#039;ve already written about those issues in my postings and publications &#8212; issues like coupling, which is huge, impedance mismatches between IDLs and language mappings, versioning, reuse, etc. In answering your question, I&#039;m therefore starting to repeat myself, which is why I said above that we&#039;ve already gotten to the bottom of this.]]></description>
		<content:encoded><![CDATA[<p>@Josh: get to the bottom of what? IMO we&#8217;ve already gone through the bottom, and now it just seems that you&#8217;re trying to argue with me on new topics just for the sake of arguing. But if you say that&#8217;s not true, I&#8217;ll give you the benefit of the doubt and try to address your question.</p>
<p>Sure, ICE, like CORBA and other systems, allows access to network-related issues. CORBA does this through exceptions that can come back to the caller from the server side or from the ORB on either side; in a language that supports true exceptions, the application will have to catch them and deal with them. Does that mean these systems are not RPC? I think it&#8217;s a gray area that can be argued either way. If you look at the code, it looks just like any local code, so from that point of view, it&#8217;s RPC. However, since it&#8217;s not necessarily trying to hide network effects and is making the programmer deal with them, then from that point of view, these systems are better in that regard than traditional RPC systems.</p>
<p>HOWEVER, and this is a big however, <em>whether or not these systems conform to some strict definition of RPC is not really the important issue; rather, the main problem is that the RPC-oriented approach in general brings with it a number of problems that go well beyond this</em>. And I&#8217;ve already written about those issues in my postings and publications &mdash; issues like coupling, which is huge, impedance mismatches between IDLs and language mappings, versioning, reuse, etc. In answering your question, I&#8217;m therefore starting to repeat myself, which is why I said above that we&#8217;ve already gotten to the bottom of this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh Haberman</title>
		<link>http://steve.vinoski.net/blog/2008/05/24/defending-something-other-than-rpc/comment-page-1/#comment-964</link>
		<dc:creator>Josh Haberman</dc:creator>
		<pubDate>Sun, 25 May 2008 19:18:43 +0000</pubDate>
		<guid isPermaLink="false">http://steve.vinoski.net/blog/?p=71#comment-964</guid>
		<description><![CDATA[Steve,

It can be hard to tell the difference between good-faith and bad-faith discussion over electronic mediums (especially when you don&#039;t know the person already), so I can&#039;t fault you for thinking that I&#039;m just being antagonistic.  Really I&#039;m trying to get to the bottom of this, but I think we&#039;ve gotten to the point where we&#039;re talking past each other.  Since you don&#039;t wish to discuss this further here, I&#039;m happy to close this discussion out and make further arguments on my blog.

Sincerely,
Josh]]></description>
		<content:encoded><![CDATA[<p>Steve,</p>
<p>It can be hard to tell the difference between good-faith and bad-faith discussion over electronic mediums (especially when you don&#8217;t know the person already), so I can&#8217;t fault you for thinking that I&#8217;m just being antagonistic.  Really I&#8217;m trying to get to the bottom of this, but I think we&#8217;ve gotten to the point where we&#8217;re talking past each other.  Since you don&#8217;t wish to discuss this further here, I&#8217;m happy to close this discussion out and make further arguments on my blog.</p>
<p>Sincerely,<br />
Josh</p>
]]></content:encoded>
	</item>
</channel>
</rss>
