Adobe AIR 1.0 - Native OS Integration Problem

Posted by Jon Rose on Jan 28, 2008

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

.NET Framework ,

.NET ,

Rich Client / Desktop ,

Architecture ,

Rich Internet Apps ,

Web 2.0 ,

Java

Tags

Apollo ,

Adobe ,

Windows ,

Flash ,

Adobe Integrated Runtime

A frequent criticism of the Adobe AIR platform is that it lacks support for native OS integration, which is typically essential when building desktop applications. With the AIR 1.0 release coming soon, Mike Chambers of Adobe published a proof of concept last week that demonstrates how developers can work around this problem.

Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.

However, this does not mean that you cannot build an AIR application that has closer / tighter integration with the underlying operating system.

...

The project is called CommandProxy. It provides a communication proxy between an AIR application and the underlying operating system and could theoretically work with other web based desktop runtimes (such as Mozilla Prism). Note, this project is in no way supported by Adobe. This is a proof of concept project that I put together to help developers understand one possible way to extend AIR functionality beyond that that is provided by the runtime.

Chambers proof of concept is fairly straightforward and easy to understand, but does it sufficiently address the native issue? Scott Barnes, a Microsoft evangelist, doesn’t believe so. He responded to Chambers post critiquing the lack of native support in the platform.

I don't know why AIR isn't looking to open its borders to native OS and it kind of illustrates the elephant in the room, in that when you go X-Platform with one bundle of code, something has to be left on the table. Native access to the operating system is one of these, and if any desktop platform is likely to succeed beyond a "Look ma, I just turned Flash into a desktop experience" then it's got to be more serious, focus on security (critically important) and ensure real world solutions can be built.

In a follow-up post Barnes detailed more of his concerns with the CommandProxy Chambers introduced:

The communication channel between the command proxy and AIR application looks like a potential vulnerability. One of the things application developers should worry about with security is insecure cross-process communication mechanisms hanging around on someone’s machine. For example if a process listens on a named pipe, and that named pipe has no ACLs and no validation of inbound communication, the process is vulnerable to all kinds of attacks when garbage is sent down the pipe. In the example on using the command proxy how do you secure it so that it doesn’t turn into a general purpose process launcher?

Chambers responded to Barnes in detail, starting with a forthright analysis of the proof of concept:

How feasible is it to actually build and deploy an application that uses a command proxy? My thoughts are that in most cases it is not feasible due to the complexity of development and distribution, although there may be instances where it could be useful.

Chambers finishes his follow-up post by touching on Adobe's plan for addressing the overarching issue:

Finally, the long term solution (and plan) is that the AIR runtime itself provide the low level functionality needed by developers. AIR 1.0 already provides access to the underlying operating system via number of APIs, and the scope of those APIs will only expand with each release.

For developers and architects in the InfoQ.com community, has this concern kept you from considering the Adobe AIR platform? Will Adobe have to fully address the native integration issue before you will be able/willing to implement desktop applications on the AIR platform?

1. Back to top

   You know, it's funny. . .

   by Gerald Anderson

   The very first project I conceived of doing based on AIR was a front-end interface to rsync, with progress bars, options settings, folder selections, etc. It was to be used by departmental non-geeks that just needed a pretty picture to look at while their backups ran.
   
   Was astonished during early research that AIR wouldn't support spawning/communicating with native apps, needless to say, that killed that idea.
   
   Ended up going to the old stand-by, Java/Swing. Blech ; )

   Reply

2. Back to top

   Holding off

   by Matt Giacomini

   I'm not going to seriously consider AIR until native OS integration is a solid component of the framework. This coming from a Flex and actionscript fan.
   
   I'm getting really tried of VM designers sand boxing us developers.

   Reply

3. Back to top

   Not so much an issue for current AIR plans

   by Roger Voss

   We already do Flex RIA web applications and so initial interest for AIR is to create hybrid versions of these apps that can also run on AIR, but with enhanced capabilities due to its additional APIs.
   
   The things in mind don't involve a need for process launching, etc. So for now would not be an issue for what we have in mind.
   
   Agree it would be good to see better interop capabilities added to the AIR runtime that facilitate more fascile native interactions, though.

   Reply

4. Back to top

   Windows native OS integration for AIR

   by Zoltan Csibi

   aperture.fluorinefx.com/

   Reply

• Older >