remote
     synthesis

Further Thoughts on Apollo

Posted on Apr 20, 2007

I have been working through my feelings on the Apollo concept lately and, in fact, had a fairly lengthy discussion with Matt Woodward and Peter Farrell about it on the ColdFusion Weekly Podcast last week. I had toyed with Apollo some, but felt that perhaps I should get a little more informed before spouting opinions (yeah, you may say, like that has ever stopped you before...touché). So, I got a copy of Apollo for Adobe Flex Developers and dove in (which isn't much diving at just over 100 very small pages...I suppose it is more wading).As I commented on both the Weekly and a recent post by Matt, there are two somewhat differing paths going on in web development. For the past couple years, companies like Google and Zoho have been moving desktop applications online. The debate seemed to be, would Windows even be a factor in a future where your desktop and applications all exist online. I have moved some of my offline apps to Google apps lately - specifically Google Docs, Calendar and Gmail, though not even 100% in those few areas. I think the consensus would be that this idea is getting closer, but isn't quite there yet - for exactly how, check out Michael Calore of Wired Magazine's recent experiences moving everything to Google in "Livin' la Vida Google".

Nonetheless, Adobe and, it seems, Microsoft are headed in a direction whereby your online apps should be replaced by connected desktop apps (or at least supplemented this way). I made the case that I thought this solved a few edge cases, but I had yet to see how this would impact the typical web-based application with the understanding that Apollo is still in the very early stages of development. After reading the book, I found some additional items I like about Apollo that might make for some fun use cases, but I am sticking with my overall opinion (while reserving final judgement for later releases).

What I Like
Expanded File I/O - The expanded file I/O APIs are the one area I saw that could solve some real-world problems at the moment - though I think they are more edge cases than common issues. For example, in my code generator the save to file feature is pretty kludgy mostly because there is no way to select a directory to save to on your local machine in either Flex or HTML. Thus, Apollo could potentially solve that problem for me, though I had never encountered this problem in any previous applications as I expect many people have not.

One interesting item regarding File I/O I noted is that it says:

Apollo will eventually provide a complete security model for managing access to local resources, such as the file system. However, this security model has not been implemented in the Apollo Alpha 1 build.

I bring this up because it is important to note where you are getting your Apollo application from since there is no security at the moment; I imagine someone could do some real damage.

Enhanced HTML Rendering with WebKit - To be quite honest, this is the only thing that got me a bit excited. You could build a five line simplistic browser and everything rendered beautifully without any of the HTML restrictions typical in Flash. However, that was not the exciting part. The exciting part was this:

Because WebKit and Flash Player are both included in the runtime, they are integrated together on a very low level. For example, when HTML is included within Flash content, it is actually rendered via the Flash display pipeline. which, among other things, means that anything you can do to a bitmap within Flash (blur, rotate, transform, etc.) can also be done to HTML.

This is covered in some detail throughout the book. The key to me here is that there was 1) *almost* no differentiation between JavaScript and ActionScript methods and variables; 2) you could create a Flex UI in HTML and have it trigger Flex event and call ActionScript methods. Let me explain a little.

Regarding the first point, I could build an HTML based interface that had JavaScript methods to do things like play audio or video or manipulate images via the Flash APIs.

Regarding the second point, an example was given where by the DOM was manipulated and an onclick method was added to an anchor tag which, when clicked, called an ActionScript method. So, as a usable example, my Apollo/Flex app could have a help system built and maintained as simple HTML files, but click something like "open the file menu" in the HTML could actually trigger the file menu to open.

What Else Is There?
The answer is, not much. At this point, many portions of the book speak of features but then note that they are not implemented yet, which often leads me to a feeling that maybe even a public alpha was premature from a technical standpoint. You have the HTML capabilities, the File I/O and the Windowing APIs - but outside of the shell that it runs in, the rest is limited to what you can currently do in Flex it appears. Considering that the windowing API doesn't solve any real problem (it only replaces the ability already existing in the browser to open new windows as far as I am concerned), you are left with two actual features that while worthy, don't make a compelling product or concept yet in my opinion.

Despite what I hear in some discussions, there was no talk of any offline data caching/synching capabilities (or even the ability to know you are offline) being implemented yet. It was however mentioned very briefly, which I suppose means it *should* be coming in a future version.

Conclusion
So, while I am moderately more excited about Apollo than I was before, I still remain unconvinced. I could see making some fun widgets with Apollo, but that doesn't solve any real world business problems to me - and I could build widgets already for OSX, Vista or even my Google home page already for that matter.

Still, I hold out hope that future alpha and beta versions will begin to offer convincing reasons that this concept has staying power (and, yes, many of us naysayers remember Central quite well), and Adobe's track record and market power definitely make this a product we need to watch.

Comments

Nice writeup, and I mostly agree with you. Where we are going to find apollo useful is in our corporate environment. Web applications are starting to really take root in the company and are replacing a lot of our legacy applications in some areas. But it has definitely been a change of culture in a lot of ways. For instance, the department has been in a "release" mind-frame for so long, its really hard for our QA and release departments to get a handle around the web applications. This would solve a lot of the issues. That and the fact that our company is built on IE for all of their web apps and you can't be sure that they haven't changed some setting like disabling cookies or turning off javascript etc, it would be great to be able to write an application that we know the "environment" that it is running in is exactly what we want and need. It should change things for our support staff and turn the perception of "web apps" in general for the company.

Posted By Ryan Guill / Posted on 04/20/2007 at 1:44 PM

I agree 100%. I don't know why people are getting so excited about making web apps run on the desktop, when web apps themselves are getting more and more powerful. I mean, when it really comes down to it, how is Apollo better than the web browser? Yes, there are the small edge cases you mentioned, but beyond that I see no difference.

Posted By Jake Munson / Posted on 04/20/2007 at 4:07 PM

Brian, I won't differ with your informed analysis of Apollo, but I'll chip in with the opinion that to me it seems a very exciting technology. Doesn't Apollo let a web application developer go where they couldn't before-- to the desktop? Now, instead of staying away from the desktop or having to learn the Windows/OSX/*nix API, we can all create desktop apps with a language close to that which we already know.

The potential uses I see (generally speaking) are website/desktop integration. If your social networking/shopping website accepts photo uploads, you can now let the user click and drag their photo to your Apollo app, kind of like Shutterfly's upload program. If you run a project management site, you could post a list of the user's meetings and tasks for the day right in their own desktop window.

I could be wrong, but it seems to me that Apollo makes for a desirable blur between online and offline apps, and it makes it significantly easier for someone to write a (limited) desktop app. I'll admit that I don't know Apollo very well, so if my suppositions aren't correct I'd be glad to learn so.

Posted By Tom Mollerus / Posted on 04/20/2007 at 5:20 PM

I agree with you Brian. I think Apollo will be fun to make some desktop widgets, but I will hold my real praise till I see a lot of companies making use of it. That is the real test of a tool, the clients that we make stuff for. If the clients don't go for it, then you aren't going to change their opinion any time soon. Clients drive the business, it isn't the necessarily the software companies the drive the business.

Posted By jeff / Posted on 04/23/2007 at 2:58 PM