<?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"
	>
<channel>
	<title>Comments on: The Hype Around Apollo - Am I Missing Something?</title>
	<atom:link href="http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/</link>
	<description>Simon Brocklehurst's Technology Blog</description>
	<pubDate>Sun, 12 Oct 2008 02:48:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: simon</title>
		<link>http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/#comment-27060</link>
		<dc:creator>simon</dc:creator>
		<pubDate>Mon, 26 Mar 2007 18:10:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/#comment-27060</guid>
		<description>Steve, thanks for taking the time to post all that.  I do get that stuff. As I said in the blog, &lt;i&gt;"I understand the point of developing Rich Internet Applications for the Desktop."&lt;/i&gt;  We were developing these kind of distributed, zero-config, self-updating non-browser, web-based technologies ten years ago.  They have big benefits for end-users over browser-based apps in certain scenarios.

The bit I don't get is what &lt;i&gt;Apollo&lt;/i&gt; adds to the mix fundamentally.  You mention runtime size as being an important differentiator.  I'm not sure that's the case - the size of the Apollo runtime will most likely end up being around the same size as the Java runtime.</description>
		<content:encoded><![CDATA[<p>Steve, thanks for taking the time to post all that.  I do get that stuff. As I said in the blog, <i>&#8220;I understand the point of developing Rich Internet Applications for the Desktop.&#8221;</i>  We were developing these kind of distributed, zero-config, self-updating non-browser, web-based technologies ten years ago.  They have big benefits for end-users over browser-based apps in certain scenarios.</p>
<p>The bit I don&#8217;t get is what <i>Apollo</i> adds to the mix fundamentally.  You mention runtime size as being an important differentiator.  I&#8217;m not sure that&#8217;s the case - the size of the Apollo runtime will most likely end up being around the same size as the Java runtime.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Sarakas</title>
		<link>http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/#comment-27030</link>
		<dc:creator>Steve Sarakas</dc:creator>
		<pubDate>Mon, 26 Mar 2007 16:10:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.psynixis.com/blog/2007/03/19/the-hype-around-apollo-am-i-missing-something/#comment-27030</guid>
		<description>Several things my friend. Even rich web apps have been largely confined to the browser. It was a big improvement when the server could actively update the client (ie AJAX w/XMLHttpRequest), even as you are working on a page, a form, or whatever. You no longer had to click when you were ready to send everything up to the server. JS could do some client side grunt work, but the server still didn't know what was going on at the client end, JS or no JS. 

Being confined to the browser means, among other things, the web app and server STILL have no access to the local resources including the disks, CPU, etc. Windows now provides Isolated Storage for .NET, and this helps a little. 

Now imagine a runtime environment that provides a "sandbox" for the web app to operate in, that grants access to the client resources. The web app can use the browser if it wants, but it doesn't have to. An application can be deployed from a server, run on the client and use all the local power and storage of the client, and more. 

Then the server wouldn't have to do all the work, only handle updates. You wouldn't have to install an application, then install update upon update upon update, on the client. Applications have to go in this direction now. Many can't keep up with the updates. As BW and connectivity increases, it makes more and more sense. 

This is just one aspect. Others are emphasizing how you will be able to continue running a web app even after a connection is lost, then when it is restored, invisibly update a session with the server. Still others emphasize how they will no longer have to support multiple versions of an application - one for MacOS, one for Windows, etc. 

Older technology made attempts to do this, because the need was seen long ago. But those failed in one way or another. They had security problems they couldn't iron out, or their runtime was huge and clunky. The Apollo runtime will succeed if it is small, and take up is as great as the Flash Player. It will play a big role in astounding improvements in web apps. The browser may well fade away. 

For an example of earlier attempts to do the above, visit the Java WebStart site and play with their Notepad demo. ActiveX was the last technology in wide use that granted a server some client side authority, but security issues have all but shut it down.</description>
		<content:encoded><![CDATA[<p>Several things my friend. Even rich web apps have been largely confined to the browser. It was a big improvement when the server could actively update the client (ie AJAX w/XMLHttpRequest), even as you are working on a page, a form, or whatever. You no longer had to click when you were ready to send everything up to the server. JS could do some client side grunt work, but the server still didn&#8217;t know what was going on at the client end, JS or no JS. </p>
<p>Being confined to the browser means, among other things, the web app and server STILL have no access to the local resources including the disks, CPU, etc. Windows now provides Isolated Storage for .NET, and this helps a little. </p>
<p>Now imagine a runtime environment that provides a &#8220;sandbox&#8221; for the web app to operate in, that grants access to the client resources. The web app can use the browser if it wants, but it doesn&#8217;t have to. An application can be deployed from a server, run on the client and use all the local power and storage of the client, and more. </p>
<p>Then the server wouldn&#8217;t have to do all the work, only handle updates. You wouldn&#8217;t have to install an application, then install update upon update upon update, on the client. Applications have to go in this direction now. Many can&#8217;t keep up with the updates. As BW and connectivity increases, it makes more and more sense. </p>
<p>This is just one aspect. Others are emphasizing how you will be able to continue running a web app even after a connection is lost, then when it is restored, invisibly update a session with the server. Still others emphasize how they will no longer have to support multiple versions of an application - one for MacOS, one for Windows, etc. </p>
<p>Older technology made attempts to do this, because the need was seen long ago. But those failed in one way or another. They had security problems they couldn&#8217;t iron out, or their runtime was huge and clunky. The Apollo runtime will succeed if it is small, and take up is as great as the Flash Player. It will play a big role in astounding improvements in web apps. The browser may well fade away. </p>
<p>For an example of earlier attempts to do the above, visit the Java WebStart site and play with their Notepad demo. ActiveX was the last technology in wide use that granted a server some client side authority, but security issues have all but shut it down.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
