Frank Sommers: Adobe released AIR 1.0 this week, along with the first open-source release of the Flex SDK. Both tools are aimed at developers interested in creating Flex-based applications. What is the relationship between AIR and the Flex SDK?

Phil Costa: AIR is a runtime. What you might want to compare it to is the Flash Player. The big difference between these is that while Flash Player allows you to deliver applications with a very rich content in the browser, AIR allows you to take all those capabilities, including the same content and skills, and develop applications that run outside the browser, on the desktop. AIR does that in the same way that Flash Player does it: it's consistent across different operating systems, provides a robust security model, and a rich set of tools around the runtime.

Frank Sommers: Why would one create a desktop application at a time when many software applications are moving to the Web and, specifically, to browser-based environments?

Phil Costa: Applications that are increasingly developed for the Internet include those that users wish to access frequently. Productivity applications, such as word processors, or photo editing, fall in that category. Users want to have a more direct connection to such applications, and desktop integration provides that.

In addition, when you start allowing people to interact with data on their hard drives, desktop integration makes that interaction much more powerful. The ability to drag a photo or a document that's on your desktop to a window so that document gets automatically uploaded, rather than having to go through two or three different browser dialogs, gives desktop integration a definite advantage.

In addition, users want to have a persistent connection to a lot of services available now on the Internet. Frequently, when an event happens in the world, a news event, or a banking transaction, or when a shipment is sent, I get an email. And the email tells me to go to a Web site, and then the Web site tells me what I wanted to know. Having a widget or a full-blown application running on my desktop allows me to get that information in a much more reliable way: The event can pop up in the system tray, for example, and, in many cases, the data could be right there for me. A desktop runtime makes that event much more user-friendly, more consumable.

Frank Sommers: There are several frameworks already to help build desktop applications. Why develop a new desktop runtime?

Phil Costa: The key reason was that for the past ten years, the primary skills people have been investing in are around Internet development technologies, whether it's HTML, JavaScript, CSS, Flex, or Flash. Development teams have invested in those skills. We wanted to make sure that they could take those skills and apply them to the desktop. With AIR, rather than having to have one set of skills and technologies for the Internet and another for desktop applications, you can just apply the same skills and, in many cases the same tools, to both.

That message has resonated very strongly with a lot of consumer companies that want to have a desktop presence for their applications as well as enterprise customers that had invested a lot in building intranet and Web-based applications but have not been able to take those applications to the desktop. Those customers want an easy way to allow those applications to work offline or integrate with other applications running on the same system.

Frank Sommers: What are some the APIs in AIR that enable those desktop integration capabilities?

Phil Costa: The AIR runtime combines a full HTML rendering engine based on WebKit, as well as the Flash Player, and provides for deeper integration between those two than is currently afforded by the plug-in APIs inside the browser. For example, you can have cross-scripting integration: events that happen in HTML can be hooked directly to event handlers in ActionScript and vice versa.

AIR also has a local database based on SQLite, and there are filesystem APIs so you can read and write files to a local disk. There are also drag-and-drop APIs: When someone drops a file onto the surface of an AIR application, the program will get a handle to the actual file itself. There are also a whole set of APIs to work with network events: for example, you can be notified whether the application has a network connection, and so on.

When you combine all those things together, you can do very rich integration with other applications, and can also manage a lot of information both online and offline. One of our customers, for example, is building a catalog application that runs inside AIR. The catalog information is pulled off the network, and can be updated whenever they add a new line or product. The application itself allows the user to make notes about products, such as what sorts of things in the catalog you like. On the one hand, it allows the user to have more privacy, because the information they're tagging the catalog with doesn't get shared with the network, and it also reduces the storage and data management needs of the service provider—they don't need to store and manage all that data.

Frank Sommers: How are AIR applications distributed to the client?

Phil Costa: When you develop an application for AIR, you package it up and digitally sign it. That creates an .air file, which is the packaging format used by the AIR runtime.

We provide a set of badges that allow you to put that .air file up on a Web site. All a user has to do is click on it, and then it will automatically detect whether the user has the runtime already installed. If they do, it will simply launch the installer, which checks the certificate and walks the user through some basic installation steps, and then installs the application. If they don't have the AIR runtime, the install badge can automatically install the runtime along with the application.

Our goal was to make that as streamlined as possible, while still making sure that the user understands that this is a desktop application and that it is digitally signed by the provider, and that they know who the provider is.

Frank Sommers: What is the security model for AIR applications? What local system resources can an AIR application access?

Phil Costa: The application has access to the local drive and can also access the network. That's one of the reasons we wanted to make sure the applications themselves were signed, since the applications have more privileges than just a Web page. We try to make sure the user is aware of what they're installing, but then we also added a pretty significant security model to make sure that one application doesn't have access to data that was stored by other applications. Our security model sandboxes the various applications, and makes sure that they can't invade another application's data area.

In AIR 1.0, the security model is pretty uniform across applications. We do plan to make that more flexible in the future, but one of our goals is to make sure it doesn't become overly complicated. Especially in enterprise situations, people want to control how much access an application has, either on a per application, or per domain, basis. We intend to invest in those kinds of APIs going forward.

Frank Sommers: To what extent is PDF integrated with AIR? Are there PDF, or Adobe Reader, APIs that would enable developers to work with existing PDF documents, or to create new ones, inside AIR?

Phil Costa: If the user running an AIR application has Adobe Reader installed on their system, an AIR application can open up a PDF document and the rendering of that document is directly integrated into the same rendering pipeline used in AIR for Flash and HTML.

As an example of that integrated rendering pipeline, if you're building a Flex application, you can load a Web page, written in HTML, and then use all the drawing APIs and graphics APIs that are part of Flash to distort the page, to shrink it, to twist it. There is a funny demo app, where a washing machine graphics loads up the Google home page and then spins it around. You can do the same thing with a PDF document.

By contrast, those rendering pipelines are separate in browser environments. Because we control all the pieces of the environment, we can integrate these much more closely.

Frank Sommers: One of the use-cases for desktop applications today is the need to display rich media types, such as music or videos. What types of rich media are supported in AIR?

Phil Costa: The AIR runtime supports all the same audio and video formats that Flash Player 9 supports. It's the same implementation embedded in the desktop runtime. AOL is demonstrating, for example, an application to browse their top one hundred videos: It allows you to download videos, play them back, and it provides a very rich way to navigate through their library.

We at Adobe are building a media player, the Adobe Media Player. It not only allows you to download and view media files, but also to store them and take them offline with you.

Frank Sommers: Do you envision integrating AIR into other Adobe products?

Phil Costa: In the past few years, Adobe has been getting into a few application areas. Adobe Media Player is an example of that. We're delivering that as an application. We also have an online version of Adobe Premiere, our video editing application, and we demoed a new version of PhotoShop Express. We also have been working on an online Word Processor. So we are building applications that sit on top of our platform technologies. Flash Player and AIR are core parts of that platform. You'll definitely see Adobe building applications on top of both of them.

That's not to say we don't encourage our partners and customers to do that as well. The fact that we're building parts of our own applications on top of our platforms shows how serious we are about making sure that they're top-notch platforms for delivering applications.

Frank Sommers: What kind of tooling support is available for developing AIR applications?

Phil Costa: Tooling for AIR starts with our own tools. We have FlexBuilder 3 for programmers who want to use the Flex framework. We've also enabled Flash authoring in DreamWeaver to target the AIR runtime with Flash and HTML content.

In addition, we've partnered with some third-party companies. One example is the Aptana Ajax IDE: Today we released a plug-in that can take an application developed in Aptana and deploy that inside the AIR runtime.

Frank Sommers: The Flex SDK has been open-sourced, but AIR has not. Are there plans to open-source AIR as well?

Phil Costa: There are several components within the AIR runtime that are open-source: The SQLite database, and the WebKit engine. In both cases, we contribute bug fixes and enhancements to those projects. Today we announced that we're joining the SQLite group and are participating in that project as well.

At the moment, we don't have specific plans to open-source the rest of AIR. But we're making all the documentation around it available, and we are open about how we're evolving it. We certainly consider the open-source model when it's an appropriate way to evolve our products. At this point, we don't think that's the right thing for AIR.

What do you think of Adobe's AIR platform?