Hands-on with Apollo

Adobe announced on Sunday night that it was releasing the first public alpha version of the Apollo runtime, which will allow end users to run Apollo applications. A few hours later, the downloads--the runtime Apollo client as well as a developer's kit--appeared on the company's site.

Finetune has made a slick Apollo-based player.

(Credit: CNET Networks)

Apollo is the new framework that allows developers to build rich applications that run without a browser, yet still take advantage of the Adobe Flash expertise that they've been using for the past few years to create cool Web-based apps. Like many other industry watchers, I've written very enthusiastic stories about Apollo. I believe it is going to be one of the key technologies in the development of hybrid applications--apps that put a rich interface on the desktop with most of the heavy lifting taking place on a Web server. Apollo is going to help Web 2.0 services escape from the confines and constraints of a Web browser. And that's great.

You can try some sample Apollo apps now, but don't expect to be terribly impressed. If you're not a developer, few are worth bothering with. Most do a good job of showing off some raw capabilities but aren't what anyone would consider must-have tools. One demo app, Lookup, is a system hog, even though it performs a very simple service: it looks up terms in online dictionaries and thesauruses. Another app, the RSS reader Fresh, doesn't let you paste feed URLs into it (you have to type them by hand or import an entire OPML file). The Finetune Desktop is very nice, though: Ii's a slick, browserless interface to the Finetune (ZDNet review) music recommendation service.

Apollo is not yet ready to take over for traditional Windows or Macintosh executables. But the release of the public alpha is an encouraging milestone. I know there are many developers eager to apply their expertise to this new platform.

For more details, see Martin LaMonica's CNET News.com story, and Ryan Stewart's post on ZDNet.com. Also, check out the upcoming Flash-based Trillian, which doesn't use Apollo--the developers said they couldn't wait.

[verdyp]

And unfortunately, say good bye to open standards

such thing is not different from other proprietary standards that were already deployed in MacroMedia Flash that Adobe bought, just to make it even more proprietary and cluttered with lots of patents!

Really, we don't need this technology; browers can continue to live, even if they implement newinteractions with a standard API based on existing open technologies: XML, ECMAscript, ... this should should be another language interoperable with others (like with CSS which could alsobe implemented with ECMAscript, or like VBScript which could be used to interact with the same object library and object model).
In fact the adove concept is not new. It's just another proprietary set of tech, that won't perform something else than what we can have in browsers today, given that it solves absolutely nothing in the most complex part of the development of interactive web appplications: the server side validation, the two-phase commit process, the management of many parallel sessions, and enforcing the security (to avoid cross-sessions attacks).

Really, I see no difference hrere with Flash applications, or with PDF appplications. Adove just demonstrates that it can create ANOTHER proprietary language, en enforcing the use of its own technology by forcing users to use a dedicated browser...

Why couldn't the Apollo browser be integrated as an API of existing browsers? There are tons of developers that will refuze to migrate their open environments to this proprietary one.

What was compliated for now was the management of many ECMAscript scriptlets to control various things related to the various implementations of HTML. But Adobe just forgets that those variations were needed, should it be only for usability, and portability to various kinds of browsing devices (including mobile phones).

So what does Adobe create here? just another web browser, that will cause new nightmares for web developers. Wasn't the past experience with the Netscape/Microsoft war enough? Now we would have to live with a new Adobe/Microsoftwar, forgetting Linux and MacOSX? Wasn't the Sun/Microsoft battle over Java enough (which makes now the Java and .Net environments live with very difficult interoperoperability issues)?
It's unfortunate that Adobe, that has participated (and still participates) to the adoption of open standards (Unicode, XML, W3C) now forgets its promisses.
The world doe not need such new split!

[verdyp]

Tons of new security issues!

Flex is definitely not a stable technology. There are TONS os new issues, and its VM (virtual machine) is really unstable.
All this look like a new competitor to Java and .Net, except that it is not proven, takes lots of machine resources, exposes many system APIs to web applications, and its whole security model is not studied.

Better live with Java, which scales better and does not differentiate between server-side, client-side or stand-alone apps, and works on all sorts of devices, ready for deployment in peer-to-peer models where all devices are capable of delivering services to each other.

Looking at the "invention" of the Flex language, it is extremely near from Java, with the same concepts, except that there are minor syntaxic variants.

Starting with the Adove showcase, it just does not work: first app loaded and installed, and immediate crash with Windows detecting an illegal access to memory (buffer overflows in stack). This just means that Apollo is not safe and can be easily targetted by new kinds of virus within Troyan AIR applications!

Really, it is muh safer to use Java WebStart for deploying desktop apps. Java already has all the tools to interat with web servers if needed, and it works in a very solid sandbox when launched in an applet running in isolation as if it was only in the remote server, with no access to the local machine.

And it's definitely SLOW!

[maddoghall]

As a developer of web-based applications....

...you only have to ask two questions:

Will my application run everyplace?
Will every user be able to see what I wanted them to see?

As long as those questions are determined by Adobe, stay away from this technology.

maddog

[peterbboswell]

More than that...

Naive my friend. Interoperability and integration are critical needs today. Productivity in the corporate workplace requires web based software where the user can integrate information from many different sources, including desktop application information and other sources, into and out of web pages, that this integration be persisted and reusable. There are millions upon millions of spreadsheets with information that flows through copy paste to web pages. This is arcane. Once done, the user must be able to persist the link, update the spreadsheet and say to a web page, grab all hundreds of my copy paste requests from dozens of spreadsheet in the past and do them again, it's a new month. Your opinion is no more advanced than that of the CICS developers of the 1980's who worked with IBM 3270 CRT's. Apollo/AIR may not be the solution, but this is the type of integration, when properly authorized by the user, that must become available.
On a consumer basis, why should I ever type my name and address more than once? Why should I depend on a web site to retain it? Why can't I create a token that fills in this information, recorded on my desktop, upon a simple authorizing click?

[moehlert]

potentially wrong direction?

I get it...this is cool and will certainly impact the browser and app development worlds but it goes the opposite direction for me and my clients' requirements. Working with organizations , both govt and commercial who have tightly locked down desktops, I am much more excited about the ability to push more and more functionality INTO the browser instead of breaking it out...try this on for a design criteria...if ti requires any kind of download...anything the user has to click a button and say yes to...its dead to me.

mark oehlert
http://blogoehlert.typepad.com/eclippings/

[WSC]

Future file

Yet another breathless article for the "Atomic Kitchen of the Future" file (that round one).