<?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: (Ext.)Direct Miss</title>
	<atom:link href="http://www.sporcic.org/2009/05/extdirect-miss/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sporcic.org/2009/05/extdirect-miss/</link>
	<description>Blog of Tim Sporcic</description>
	<lastBuildDate>Mon, 19 Jul 2010 08:33:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tim</title>
		<link>http://www.sporcic.org/2009/05/extdirect-miss/comment-page-1/#comment-174</link>
		<dc:creator>Tim</dc:creator>
		<pubDate>Mon, 18 May 2009 14:31:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.sporcic.org/?p=375#comment-174</guid>
		<description>Hi Steve. The concept of abstracting out the server communication layer via Ext.Direct is valuable, but they picked the wrong level of abstraction. Rather than specifying an RPC protocol all the way down to the server, it would have made more sense to design Ext.Direct to take client-side plugins for different server technologies. For example, rather then implement a new server-side stack for Java, they could instead plug in DWR underneath Ext.Direct and achieve their desired level of abstraction. 

Defining a new RPC protocol is only helpful for the server technologies that don&#039;t have those stacks clearly defined (PHP, ColdFusion, etc...) The enterprise technology stacks which are the ExtJS sweetspot (Java, .NET) already have several protocol stacks for addressing this problem. 

-Tim</description>
		<content:encoded><![CDATA[<p>Hi Steve. The concept of abstracting out the server communication layer via Ext.Direct is valuable, but they picked the wrong level of abstraction. Rather than specifying an RPC protocol all the way down to the server, it would have made more sense to design Ext.Direct to take client-side plugins for different server technologies. For example, rather then implement a new server-side stack for Java, they could instead plug in DWR underneath Ext.Direct and achieve their desired level of abstraction. </p>
<p>Defining a new RPC protocol is only helpful for the server technologies that don&#8217;t have those stacks clearly defined (PHP, ColdFusion, etc&#8230;) The enterprise technology stacks which are the ExtJS sweetspot (Java, .NET) already have several protocol stacks for addressing this problem. </p>
<p>-Tim</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve 'Cutter' Blades</title>
		<link>http://www.sporcic.org/2009/05/extdirect-miss/comment-page-1/#comment-173</link>
		<dc:creator>Steve 'Cutter' Blades</dc:creator>
		<pubDate>Mon, 18 May 2009 14:11:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.sporcic.org/?p=375#comment-173</guid>
		<description>I think Direct was a great path for 3.0, but I think it might be a while before you see widespread adoption. Over the weekend I went through the ColdFusion stack, written by Aaron Conran (The Team Lead on Ext JS, and a long time ColdFusion developer). It works, and is written well, but I wouldn&#039;t call it &#039;enterprise ready&#039;. Then again, I don&#039;t think that was what they were going for either. Here you have a group of developers, who write a rock star client-side framework, writing server-side examples.

And that&#039;s what they really are, examples. I think this is why they give us the full router guidelines, so that we, as a community, can come up with the best implementation for our particular environment. The provided stacks give us insight into what is required, after which we can adjust where we feel it&#039;s necessary.</description>
		<content:encoded><![CDATA[<p>I think Direct was a great path for 3.0, but I think it might be a while before you see widespread adoption. Over the weekend I went through the ColdFusion stack, written by Aaron Conran (The Team Lead on Ext JS, and a long time ColdFusion developer). It works, and is written well, but I wouldn&#8217;t call it &#8216;enterprise ready&#8217;. Then again, I don&#8217;t think that was what they were going for either. Here you have a group of developers, who write a rock star client-side framework, writing server-side examples.</p>
<p>And that&#8217;s what they really are, examples. I think this is why they give us the full router guidelines, so that we, as a community, can come up with the best implementation for our particular environment. The provided stacks give us insight into what is required, after which we can adjust where we feel it&#8217;s necessary.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
