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.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.
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.
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?