Thank you for the reply, we all appretiate the fact that adobe pays attention to the community.

_
Mrinal

That said, the community has spoken loud and clear about native code. I haven’t seen an official to-do list for future versions, but I know Adobe is very good about listening to the community. If I have any public info we’ll keep you posted.

=Ryan
rstewart@adobe.com

I hope, Adobe would find a way (usability, HCI, security or whatever) to provide more flexibility…

Let’s keep our fingers crossed, oh no, lets write custom installers (or use one being open-sourced by Claus) and write socket-servers

-abdul

A truely professional feel can only be achieved if Adobe allows us to extend the AIR application installer … or if they allow us to install air apps silently .. without the wizards ….. i can already hear security alarms … weird

Security: Mrinal already made valid points. A simple solution would be to add a Shell.exec() method to the API that allows to launch executables. If Shell.exec() would be limited to executables in the application resource directory, i wouldn’t see any security problems.

Platform dependencies: One could for example write local RPC socket servers for all supported platforms that implement all additional, platform dependent functionality which is needed. The AIR application would then just start the local RPC server via Shell.exec() on launch and then call methods on it. Easy and cross platform. I did exactly that for an AIR app i am currently developing and it works like a charm - it’s just a pain to deploy.

I bet my right arm that there will be many developers and customers who are going to complain about the lack of extensibility, and as a result go elsewhere. Is that in Adobe’s interest? Right now it very much sounds like.

I’m not complaining here .. AIR is awesome !!! and I totally love it … this post is just an attempt to get such native support on Adobe’s todo list.

John,

The above message shows up when a user tries to install an AIR app, once he accepts, he has already done all the thinking he will ever do. There is no distinction here that tells him this is less dangerous than the .msi or the .dmg that he installed earlier.

File IO can be equally dangerous, If you cannot kill a process, you can easily go and delete all the files it is dependent on to cause an equivalent chaos.

My point is, users today know the security threat that comes with installing on the desktop and once they have allowed you to install an their desktop they expect features from your app that all desktop software have.

Let me give a simple example, recently I was developing an app that needed to launch urls in the browser, now air can do this but after the navigateToURL call its up to the browser to handle the launch …. now IE has this habit of taking new windows to the taskbar and blinking and not showing them to the user … my client hated this …. he pointed me to outlook and said outlook launches all urls in IE windows that never go to the taskbar … it was hard for me to explain to him that I do not have any control over IE while outlook does

This is just a simple example of how users start expecting true desktop abilities once they allow you to install on the desktop.

To get around the security concerns you could just have AIR notify the user the first time an app tries to spawn or kill another process.

Derek

Prioritizing developer desires over potential consumer desires is what led Microsoft to its security failures in the 1990s. Lots of people thought it would be great to execute JavaScript and ActiveX in email, for instance.

Right now, if your device drivers exposes a web connection you can communicate through server connections. But killing off other applications… that may reduce acceptance more than it increases it.

jd/adobe