Rags to Riches

en route to a “richer” Internet

1. John Dowdell 11.25.07 / 5am

   Those are developer desires, but they have to be paired against consumer desires. You’d think twice about installing applications that had device drivers, or ones that could control other applications on your machine.

   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
2. Claus Wahlers 11.25.07 / 7am

   John, developer desires often echo customer desires.
3. Derek Wischusen 11.25.07 / 8am

   I’d also think twice before I installed an application that has access to my File I/O.

   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
4. Mrinal Wadhwa 11.25.07 / 4pm

   System Access: UNRESTRICTED
   “Installing applications may present a security risk to you and your computer. Install only from sources that you trust.”

   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.
5. Benz 11.25.07 / 5pm

   I always say to myself that this is a 1.0 product. I`m pretty sure we`ll get all this native stuff in further versions. Then AIR will rock even more!
6. Mrinal Wadhwa 11.25.07 / 5pm

   I sure hope so Benz … after talking to people in Adobe I do not get that feeling though and hence this post

   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.
7. Claus Wahlers 11.25.07 / 5pm

   As far as i understand the two top-of-the-list reasons given by Adobe why AIR is not extensible in any way are security concerns and potential platform dependencies.

   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.
8. Mrinal Wadhwa 11.25.07 / 6pm

   I don’t mind the socket sever approach but as Claus mentions …. in the current situation “it’s just a pain to deploy” … you need two separate installers … and the user needs to start two different executables .. the server and the air app … you can make subtle improvements to this experience but it still stays pretty much ugly.
9. Claus Wahlers 11.25.07 / 6pm

   Some thoughts on installer solutions:
   http://wahlers.com.br/claus/blog/custom-installer-for-adobe-air-applications/
10. Mrinal Wadhwa 11.25.07 / 6pm

    That is an interesting approach Claus, probably the best option available yet …. but even with that approach the user is going to get a disconnected experience ….. it will still not be one continuously flowing wizard that takes him through the whole installation … he will first see your installer .. then the air runtime installer .. then the air application installer … this is not how professional apps should be.

    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
11. Abdul Qabiz 11.25.07 / 11pm

    All points above have been discussed a lot over different places (blogs, mailing-lists etc), Adobe has some reason not to do it… Developers have more reasons to ask for this feature…

    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
12. Ryan Stewart 11.28.07 / 7am

    Hey Mrinal, we definitely hear you. From what I gather the main reason it wasn’t in 1.0 was a combination of time/resources and the fact that we want AIR 1.0 to be truly cross platform. Once you introduce native code that gets tricky.

    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
13. Mrinal Wadhwa 11.28.07 / 12pm

    Hi Ryan,

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

    _
    Mrinal