Every fledgling technology has misconceptions about it until people get more exposure to it, have used it, have developed with it, and understand the intent and limitations of that technology. AIR is no exception.

Adobe calls AIR "a new technology that makes possible exciting new software applications that merge the desktop and the web." I've emphasized "software applications" for a reason: the goal of AIR is to build desktop applications. The great part of it is that applications can be build using technologies familiar to web developers including Flash, Flex, and the web standards trio, HTML, CSS and JavaScript.

Robert O'Callahan, a Mozilla developer has, after hearing about AIR, raised some concerns, specifically regarding application sandboxing and custom chrome. I'll touch on both and why I believe neither are not serious issues, at least as to how they apply in the context of building a desktop application.

Application Sandboxing

If you have some familiarity with AIR, keep in mind that we're talking about an applications ability to communicate with the OS, the file system and other resources.

Robert says,

AIR doesn't sandbox apps, so users have to make a trust decision to use an AIR app. I don't know how high a barrier that is to AIR app adoption; I hope it's a high one, because users should be reluctant to let applications abuse them!

Desktop applications right now don't have that kind of sandboxing and if AIR did do this, the users would either have to opt-in to a higher degree of OS access (reminiscent of Vista's persistent security questions) or you're left with an application that really isn't much better than a web application.

Much of AIR's attraction comes from the ability to run applications locally. We're not just trying to create web applications or web sites; we're trying to build desktop applications first and foremost. You can use AIR to build applications that have no connection with the Internet (a to-do list is a great example of this).

Custom Chrome

Likewise, building a desktop application has different considerations than building a web application for the web. How code is structured and how an application behaves will be different in a standalone, desktop environment than it is on the web. Sure, they can be quite similar but building a desktop application has different considerations.

Every application is different, of course, but generally speaking, desktop applications have a single "view" that continually updates with new information and is supported with a few other views. While many web-based applications like webmail have been moving to a similar model, they often break down because of the constraints and controls of the web browser. Back buttons have often caused frustration for users who've suddenly found their information lost instead of just undoing the most recent task and caused frustration for developers who have to work around these limitations.

Robert says,

Another, related difference is that AIR lets apps escape browser chrome such as the forward/back buttons and the address bar. I can see that app designers would love that --- yay for integrity of artistic vision! --- but I'm not sure users would. Browser navigation (back, forward, bookmarks, addresses and autocomplete) is a powerful mental model that is not only deeply entrenched but is actually very useful.

You'll notice he said, "browser chrome" but AIR is not a browser, despite using WebKit. It's a platform for building applications that have no use for forward/back buttons, an address bar, or bookmarks.

What AIR does do is allow for custom chrome instead of the standard OS chrome. With instant messaging clients and media players, custom OS chrome is very commonplace (although this may be moreso on Windows than on OSX). There are considerations that come with taking that step but I don't feel that it is inherently a bad thing nor is it just for the integrity of artistic vision. It's about making an application as useful as possible and sometimes that means escaping the OS chrome. (Okay, sometimes it is just about the artistic vision!)

It's a desktop application

To me, AIR works because of its familiarity and its ability to easily run cross-platform but this is with the understanding that we're building desktop applications, not web applications, despite the fact that we're using the same technologies.