<?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: Why Apollo?</title>
	<atom:link href="http://blogs.adobe.com/mesh/2007/03/why_apollo.html/feed" rel="self" type="application/rss+xml" />
	<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html</link>
	<description>Mike Chambers. Senior Product Manager, Developer Relations at Adobe.</description>
	<lastBuildDate>Mon, 23 Apr 2007 14:30:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jean-francois Nepton</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7291</link>
		<dc:creator>Jean-francois Nepton</dc:creator>
		<pubDate>Fri, 20 Apr 2007 03:35:39 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7291</guid>
		<description>I have heard mentioning of more audio support, would this happen to include support for recording audio from the microphone and saving to the local file system as opposed to just hearing the sound with Flash&#039;s default API?</description>
		<content:encoded><![CDATA[<p>I have heard mentioning of more audio support, would this happen to include support for recording audio from the microphone and saving to the local file system as opposed to just hearing the sound with Flash&#8217;s default API?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SimonH</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7290</link>
		<dc:creator>SimonH</dc:creator>
		<pubDate>Tue, 03 Apr 2007 02:08:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7290</guid>
		<description>Having to install the runtime before you run the app could be a problem for some people. But, because the Apollo app may have a link with an existing web application you&#039;re already using, the incentive to install it is much greater than Java.The Ebay app is a good example, it&#039;s not reinventing Ebay, just extending it. A user would much rather install the Apollo runtime that extends Ebay over the Java runtime for an untested/unused Java auction app.</description>
		<content:encoded><![CDATA[<p>Having to install the runtime before you run the app could be a problem for some people. But, because the Apollo app may have a link with an existing web application you&#8217;re already using, the incentive to install it is much greater than Java.The Ebay app is a good example, it&#8217;s not reinventing Ebay, just extending it. A user would much rather install the Apollo runtime that extends Ebay over the Java runtime for an untested/unused Java auction app.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eelco Hillenius</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7289</link>
		<dc:creator>Eelco Hillenius</dc:creator>
		<pubDate>Mon, 02 Apr 2007 20:31:49 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7289</guid>
		<description>Great article, and certainly interesting technology. Most applications I&#039;ve worked on the last years would certainly have taken advantage of such a mixed model.If I may add my two cents:* It&#039;s unfortunate that there is no role for a Java. The prospect of having to use JavaScript for more than a little tweak here and there would be a big turn-off for me (and many fellow programmers I&#039;m sure).* The conflicting UI argument makes sense, but has two sides to it. I think that many of the leading web applications, especially some of the 2.0 apps, got popular because they had a UI that set them apart, as much for the looks and innovations as for the bare functionality.</description>
		<content:encoded><![CDATA[<p>Great article, and certainly interesting technology. Most applications I&#8217;ve worked on the last years would certainly have taken advantage of such a mixed model.If I may add my two cents:* It&#8217;s unfortunate that there is no role for a Java. The prospect of having to use JavaScript for more than a little tweak here and there would be a big turn-off for me (and many fellow programmers I&#8217;m sure).* The conflicting UI argument makes sense, but has two sides to it. I think that many of the leading web applications, especially some of the 2.0 apps, got popular because they had a UI that set them apart, as much for the looks and innovations as for the bare functionality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Timothy Huertas</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7288</link>
		<dc:creator>Timothy Huertas</dc:creator>
		<pubDate>Sat, 31 Mar 2007 10:15:38 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7288</guid>
		<description>Thank you for taking the time to write such an awesome article!  It is exactly the type of overview I was looking for.RegardsTim</description>
		<content:encoded><![CDATA[<p>Thank you for taking the time to write such an awesome article!  It is exactly the type of overview I was looking for.RegardsTim</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Lord</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7287</link>
		<dc:creator>Simon Lord</dc:creator>
		<pubDate>Sat, 31 Mar 2007 07:32:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7287</guid>
		<description>I have to agree with Brian on this one.  We were hoping that Apollo was a wrapper for our apps so that we could create an installer for our clients to run.  But now it looks like we need to get our clients to install Apollo first THEN install our app?  How is this appealing?  Psycologically this makes the apps more complex because users have to install &quot;all this other stuff&quot;.Ok, yes, once Apollo is installed then the user can omit that step.  But how does THAT make our documentation any easier or smaller?  Now we have to descibe HOW to *check* for Apollo AND how to *install* Apollo or how to *update* Apollo.  That&#039;s a LOT of extra documentation to write in *our* product docs about ANOTHER companies product.This is no different than having to ask users to install HyperCard in order to run Stacks.  And, as Brian suggests, the act of having to depend on the user to go through all these hoops to install Apollo before installing our app is for us, simply too risky.</description>
		<content:encoded><![CDATA[<p>I have to agree with Brian on this one.  We were hoping that Apollo was a wrapper for our apps so that we could create an installer for our clients to run.  But now it looks like we need to get our clients to install Apollo first THEN install our app?  How is this appealing?  Psycologically this makes the apps more complex because users have to install &#8220;all this other stuff&#8221;.Ok, yes, once Apollo is installed then the user can omit that step.  But how does THAT make our documentation any easier or smaller?  Now we have to descibe HOW to *check* for Apollo AND how to *install* Apollo or how to *update* Apollo.  That&#8217;s a LOT of extra documentation to write in *our* product docs about ANOTHER companies product.This is no different than having to ask users to install HyperCard in order to run Stacks.  And, as Brian suggests, the act of having to depend on the user to go through all these hoops to install Apollo before installing our app is for us, simply too risky.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Lee</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7286</link>
		<dc:creator>Brian Lee</dc:creator>
		<pubDate>Fri, 30 Mar 2007 09:07:55 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7286</guid>
		<description>Why Apollo will probably not make it (or how Flash kicked Java&#039;s ass as a Web UI)?I could be wrong, but if Apollo&#039;s install is a lot longer and larger than Flash&#039;s installation, say closer to Java&#039;s time to install (think of it on the consumer&#039;s end as opposed to developer&#039;s), Apollo will suffer the same fate as java for the consumer. Not many people want to take time to install something that doesn&#039;t do anything specific (instant messaging, playing music, etc...). This is why web apps and flash games have taken off in popularity - most people just don&#039;t like to install software.This isn&#039;t Macromedia/Adobe&#039;s first time in trying to do this. If I remember correctly there was a desktop version of flash as well. Those who don&#039;t study history, tend to repeat it....</description>
		<content:encoded><![CDATA[<p>Why Apollo will probably not make it (or how Flash kicked Java&#8217;s ass as a Web UI)?I could be wrong, but if Apollo&#8217;s install is a lot longer and larger than Flash&#8217;s installation, say closer to Java&#8217;s time to install (think of it on the consumer&#8217;s end as opposed to developer&#8217;s), Apollo will suffer the same fate as java for the consumer. Not many people want to take time to install something that doesn&#8217;t do anything specific (instant messaging, playing music, etc&#8230;). This is why web apps and flash games have taken off in popularity &#8211; most people just don&#8217;t like to install software.This isn&#8217;t Macromedia/Adobe&#8217;s first time in trying to do this. If I remember correctly there was a desktop version of flash as well. Those who don&#8217;t study history, tend to repeat it&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: leslie</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7285</link>
		<dc:creator>leslie</dc:creator>
		<pubDate>Thu, 29 Mar 2007 09:44:44 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7285</guid>
		<description>Some thoughts on Apollo, XUL, and WPFe:&lt;a href=&quot;http://jinsync.com/?q=node/12&quot; rel=&quot;nofollow&quot;&gt;&lt;a href=&quot;http://jinsync.com/?q=node/12&quot; rel=&quot;nofollow&quot;&gt;http://jinsync.com/?q=node/12&lt;/a&gt;&lt;/a&gt;~L</description>
		<content:encoded><![CDATA[<p>Some thoughts on Apollo, XUL, and WPFe:<a href="http://jinsync.com/?q=node/12" rel="nofollow"></a><a href="http://jinsync.com/?q=node/12" rel="nofollow">http://jinsync.com/?q=node/12</a>~L</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jamie Badman</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7284</link>
		<dc:creator>Jamie Badman</dc:creator>
		<pubDate>Thu, 29 Mar 2007 07:40:33 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7284</guid>
		<description>The biggest problem from a personal point of view, using Apollo is, in a large corporate intranet - which is the arena I&#039;ve developed in for the last five years or so, desktop security is often very tight. This means that installing a new application can often not be accomplished by a standard user; a support call needs to be placed for a support engineer to install a required application - provided it&#039;s been passed by an apps security group etc etc.This has been the great strength of developing apps in Flex (or prior to that, Flash/Firefly etc). All that was needed was approval for Flash to be installed on the corporate build and everything else just works.Apollo steps back a little in that regard though; it&#039;s back to &#039;each application has its own install&#039; and therefore is likely to run afoul of corporate security/policy.However... all the above might be total rubbish - I&#039;ve not tried Apollo yet - except to install a few demos on my PC - *perhaps* an install is less than it appears to be - if, for example, an Apollo install (assuming the runtime already exists on the PC) is actually the transfer of a single file/directory onto the user&#039;s machine - with no registry or system modification - then *maybe* this isn&#039;t such a problem - because of course each user will *always* have a writeable directory somewhere. Is this the case ? Or is an Apollo app install spreading itself out and about on the user&#039;s machne ?Cheers,Jamie.</description>
		<content:encoded><![CDATA[<p>The biggest problem from a personal point of view, using Apollo is, in a large corporate intranet &#8211; which is the arena I&#8217;ve developed in for the last five years or so, desktop security is often very tight. This means that installing a new application can often not be accomplished by a standard user; a support call needs to be placed for a support engineer to install a required application &#8211; provided it&#8217;s been passed by an apps security group etc etc.This has been the great strength of developing apps in Flex (or prior to that, Flash/Firefly etc). All that was needed was approval for Flash to be installed on the corporate build and everything else just works.Apollo steps back a little in that regard though; it&#8217;s back to &#8216;each application has its own install&#8217; and therefore is likely to run afoul of corporate security/policy.However&#8230; all the above might be total rubbish &#8211; I&#8217;ve not tried Apollo yet &#8211; except to install a few demos on my PC &#8211; *perhaps* an install is less than it appears to be &#8211; if, for example, an Apollo install (assuming the runtime already exists on the PC) is actually the transfer of a single file/directory onto the user&#8217;s machine &#8211; with no registry or system modification &#8211; then *maybe* this isn&#8217;t such a problem &#8211; because of course each user will *always* have a writeable directory somewhere. Is this the case ? Or is an Apollo app install spreading itself out and about on the user&#8217;s machne ?Cheers,Jamie.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7283</link>
		<dc:creator>Brian</dc:creator>
		<pubDate>Thu, 29 Mar 2007 07:17:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7283</guid>
		<description>My question is how large is the Apollo runtime for normal users? If it&#039;s a lot bigger than say a flash download, then Apollo suffers from the same major weakness that Java suffers from.Flash installation seems automatic and painless... if Apollo isn&#039;t the same, then that&#039;s one strike against it.</description>
		<content:encoded><![CDATA[<p>My question is how large is the Apollo runtime for normal users? If it&#8217;s a lot bigger than say a flash download, then Apollo suffers from the same major weakness that Java suffers from.Flash installation seems automatic and painless&#8230; if Apollo isn&#8217;t the same, then that&#8217;s one strike against it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander Marktl</title>
		<link>http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7282</link>
		<dc:creator>Alexander Marktl</dc:creator>
		<pubDate>Thu, 29 Mar 2007 05:45:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.adobe.com/mesh/2007/03/why_apollo.html#comment-7282</guid>
		<description>I also thought about that. You know: will Apollo replace the browser? Will it be a new Browser...I&#039;m currently working on an Apollo based Business Application. Today such apps are still mainly classical desktop software but there are some attempts that bring them Online.The problem is: Browsers are just not the best way to do such an Application but on the otherside the Internet just has so many advantages (no installs, no backups, no updates, access everywhere ...).Apollo is the solution: It&#039;s a combination of both worlds.But why is it a complement to the Browser and not a replacement?Well there are still situations where you just cannot or don&#039;t want to install a desktop app, like at public PCs, at your private PC,...The really cool thing with Apollo is, that we don&#039;t have to decide between Web or Desktop anymore. Just take your existing code and with a few modifications it runs within a Browser or on the Desktop.You can offer both versions to your customers and let them decide, what they prefer...Btw: I&#039;m using Flex Builder since 3 months now and the learning curve is massive.</description>
		<content:encoded><![CDATA[<p>I also thought about that. You know: will Apollo replace the browser? Will it be a new Browser&#8230;I&#8217;m currently working on an Apollo based Business Application. Today such apps are still mainly classical desktop software but there are some attempts that bring them Online.The problem is: Browsers are just not the best way to do such an Application but on the otherside the Internet just has so many advantages (no installs, no backups, no updates, access everywhere &#8230;).Apollo is the solution: It&#8217;s a combination of both worlds.But why is it a complement to the Browser and not a replacement?Well there are still situations where you just cannot or don&#8217;t want to install a desktop app, like at public PCs, at your private PC,&#8230;The really cool thing with Apollo is, that we don&#8217;t have to decide between Web or Desktop anymore. Just take your existing code and with a few modifications it runs within a Browser or on the Desktop.You can offer both versions to your customers and let them decide, what they prefer&#8230;Btw: I&#8217;m using Flex Builder since 3 months now and the learning curve is massive.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

