Comments on: Apollo and RIA Thoughts http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/ Wed, 20 Aug 2008 09:38:26 +0000 http://wordpress.org/?v=2.5 By: leslie http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-1058 leslie Thu, 22 Mar 2007 18:56:15 +0000 http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-1058 I started tinkering with XUL when Mozilla 0.9.1 came out, and almost seven years later, it's not that much easier to write an app in XUL. Openness is nice, but as <a href="http://lwu.vox.com/library/post/ux.html" rel="nofollow">I wrote elsewhere</a>, "if the UX rocks, it's (probably) not free". ~L I started tinkering with XUL when Mozilla 0.9.1 came out, and almost seven years later, it’s not that much easier to write an app in XUL.

Openness is nice, but as I wrote elsewhere, “if the UX rocks, it’s (probably) not free”.

~L

]]> By: John Dowdell http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-889 John Dowdell Fri, 02 Mar 2007 22:26:10 +0000 http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-889 Thanks for the comments, Mark. That "platform openness: can you fork or hack the system?" topic is an interesting one for me... I see layers of functionality, stacked atop each other, and some parts different individuals can change, other parts they cannot. This is particularly true with clientside engines: things which run on Other Peoples Machines. With Apollo, as I currently understand, you can hack any app you wish, any interface, using either SWF or HTML/JS. You can't change the engine someone has installed on their machine to render your SWF or HTML/JS, but you can confidently deploy atop that predictable capability on their machines. We've got two dynamics here: the urge to customize and control our own devices and our own operating environment, and the value in providing others with a known capability to work within upon our own machines (and, conversely, each of our abilities to predictably deploy upon the machines of others). In a sense, the API is not a hackable layer -- there are reasons that no HTML browser renders STRONG as BLINK -- the assumption of particular capabilities on Other Peoples Machines allows us to deploy whatever we wish <em>within</em> that known API. The section on extensions is also of interest to me. Again, it's a layering thing... getting your own OS-native code onto Other Peoples Machines is always difficult. But getting your own ECMAScript customizations onto the known engines on the world's machines then becomes easy. I don't know of any Adobe work in making it easier for other people to adopt your own system-level code, but I do know that much of the Adobe work is in providing a predictable cross-OS platform atop which anyone can then deploy. XULRunner is probably one of the closest models, I agree -- both seem to attempt to provide a common and widely-trusted framework, upon which anyone is then free to build. It's a work in progress, though, and like most new things, will take a lot of experimentation and consensus to finally get right. If you could help in this guidance when it arrives, then that'd be great... thanks! jd/adobe Thanks for the comments, Mark.

That “platform openness: can you fork or hack the system?” topic is an interesting one for me… I see layers of functionality, stacked atop each other, and some parts different individuals can change, other parts they cannot. This is particularly true with clientside engines: things which run on Other Peoples Machines.

With Apollo, as I currently understand, you can hack any app you wish, any interface, using either SWF or HTML/JS. You can’t change the engine someone has installed on their machine to render your SWF or HTML/JS, but you can confidently deploy atop that predictable capability on their machines.

We’ve got two dynamics here: the urge to customize and control our own devices and our own operating environment, and the value in providing others with a known capability to work within upon our own machines (and, conversely, each of our abilities to predictably deploy upon the machines of others). In a sense, the API is not a hackable layer — there are reasons that no HTML browser renders STRONG as BLINK — the assumption of particular capabilities on Other Peoples Machines allows us to deploy whatever we wish within that known API.

The section on extensions is also of interest to me. Again, it’s a layering thing… getting your own OS-native code onto Other Peoples Machines is always difficult. But getting your own ECMAScript customizations onto the known engines on the world’s machines then becomes easy. I don’t know of any Adobe work in making it easier for other people to adopt your own system-level code, but I do know that much of the Adobe work is in providing a predictable cross-OS platform atop which anyone can then deploy.

XULRunner is probably one of the closest models, I agree — both seem to attempt to provide a common and widely-trusted framework, upon which anyone is then free to build.

It’s a work in progress, though, and like most new things, will take a lot of experimentation and consensus to finally get right. If you could help in this guidance when it arrives, then that’d be great… thanks!

jd/adobe

]]> By: enefekt http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-888 enefekt Fri, 02 Mar 2007 21:59:39 +0000 http://starkravingfinkle.org/blog/2007/03/apollo-and-ria-thoughts/#comment-888 I view it as a set of trade-offs. I've developed 4 applications with XULRunner, and a few with the Flex 2 SDK. Apollo will likely have great documentation (guess based off of Flex 2/ActionScript 3 Docs), it will be clear and quick to develop for. XULRunner, and related technologies (currently) have spotty documentation, the learning curve can be a little steep to grasp all the different tentacles. (XUL, XBL, XPCOM, etc.) A very important aspect to watch closely will be the user experience for application *and* runtime installation. Also management and versioning of that runtime. We will get to see how Apollo handles it very soon here. I haven't seen anything promising so far for streamlined runtime and app installation for XULRunner. So that is something I am eagerly awaiting. I like XULRunner a lot, and developing with it. And you're right, if you need to create a native code component, XULRunner wins on that. I also like developing with Flex/ActionScript, less hassle for whipping an app together. Looks like both Firefox 3 and Apollo are set to be having final releases Q4 07, so it will interesting to see how they end up getting used, and what their individual strengths and weaknesses are. I view it as a set of trade-offs. I’ve developed 4 applications with XULRunner, and a few with the Flex 2 SDK.

Apollo will likely have great documentation (guess based off of Flex 2/ActionScript 3 Docs), it will be clear and quick to develop for.

XULRunner, and related technologies (currently) have spotty documentation, the learning curve can be a little steep to grasp all the different tentacles. (XUL, XBL, XPCOM, etc.)

A very important aspect to watch closely will be the user experience for application *and* runtime installation. Also management and versioning of that runtime.

We will get to see how Apollo handles it very soon here. I haven’t seen anything promising so far for streamlined runtime and app installation for XULRunner. So that is something I am eagerly awaiting.

I like XULRunner a lot, and developing with it. And you’re right, if you need to create a native code component, XULRunner wins on that.

I also like developing with Flex/ActionScript, less hassle for whipping an app together.

Looks like both Firefox 3 and Apollo are set to be having final releases Q4 07, so it will interesting to see how they end up getting used, and what their individual strengths and weaknesses are.

]]>