ColdFusion makes developing web applications insanely quick and easy. I don’t need to worry about the nuts and bolts of how to connect to a database, or how to invoke a web service, or how to read and write files on the server. I just write straightforward tags in my favorite text editor — and I’m done, web application launched for all the world to use.

But there are some things that web applications can’t do. They can’t really read and write files on the client machine. They can’t interact much with the client operating system. Drag and drop, PDF manipulation, copy and paste… the list goes on. And all that aside, an Internet application will never work without an Internet connection.

So how do you go about creating something that can do those things? A couple years ago, you were stuck building complex and clunky binary applications. So you have to dig into lower level languages like Java, C++, or any of the .Net languages.

Suddenly you’re working with compilers and writing 300 commands to do what one tag does in ColdFusion. Sure, you’re scoring points with the Java and .Net purists. But all that doesn’t leave a ton of time for the trivial things like the interface or user experience.

Enter the Adobe Integrated Runtime — AIR. You can use AIR to write a desktop application in Flex XML and ActionScript, or HTML and JavaScript. AIR exposes hooks in to the client system to handle a local database connection, catch drag and drop events, open up local files, and even render PDF documents.

So instead of writing complex machine code, you’re back to writing tags to define the interface. And you’re calling a simplified scripting API to do heavy lifting under the covers. And the API runs on both Windows and Mac, so your pool of potential users is not limited to one operating system.

Have you already written a full web application in Flex or AJAX? You’re only a few steps away from adapting the same code to run either online, or on the desktop. Maybe it’s a little of both.

Flickr has offered a pretty slick upload tool for a few years now. It’s an executable that you can install on your desktop to do drag and drop file uploads. Somebody at Flickr had to develop separate binary Windows and Mac executables.

With AIR, that’s something you could in one shot. Don’t believe me? Check out Matt Chotin’s MediaWiki uploader AIR app. They’re different underlying services, but it’s a great example of how a web app can be extended to the desktop.

AIR does a lot to bridge the gap between web and desktop apps. But just like ColdFusion did for web scripting, it makes building all the parts easy. And you get to use tools that you already know exactly how to use.

Now you can get back to focusing on what’s really important: building better software.

A coworker of mine has been researching secure Flex 2 remote object calls to ColdFusion cfc’s over HTTPS. Seems simple enough, but anytime sensitive information is passed over the Internets I’d really like it to be bulletproof. Sure, I’m comfortable with HTTPS, but opening a flash swf over HTTP and trusting that it’s using HTTPS behind the scenes makes me a queasy system admin.

By default, a Flash movie can only access data through the exact domain where it was itself accessed. So, when you open a Flash swf over HTTP it can’t open a remote object over HTTPS to the same domain. The data host server can be tweaked to allow HTTP to HTTPS communication. But do I really want to make this tweak?

Adobe has this to say about it in a Flash tech note:

A secure server that allows access to movies hosted via a non-secure protocol
It is not advisable to permit HTTP content to access HTTPS content. This practice can compromise the security offered by HTTPS.

Most of the developers using our CF servers for Flex purposes are only using HTTPS for authentication. The rest of their app data is generally non-sensitive and doesn’t require encryption.

Is there really a security risk in opening a swf over HTTP and then making HTTPS remote object calls? If the endpoint is set in the Flex 2 app to an https address, all signs indicate that communication from the swf is going over HTTPS.