Kevin Hoyt

There is a fantastically interesting conversation happening on the “Apollo Coders” Yahoo! Group. The original message comes in from Jeff Houser of The Flex Show fame, and is about wanting to build an AIR application for a client. The requirements however, and the responses from the list, pretty quickly nail this as distinctly not an AIR application. I couldn’t help but wonder however, what functional changes to the requirements would make this an AIR application?

The most notable requirements from Jeff’s customer include accessing a local MS Access database, and being able to integrate pretty deeply with Word, Excel and PDF on the client. This is clearly working with Microsoft products on a Microsoft desktop, and the list goes on to suggest WPF, which is probably the right direction. Adobe AIR is about bringing the web to the desktop in a cross-platform manner, not the desktop to the web.

When we talk about the extending the web, we’re talking about a world of service-oriented architectures (SOA), social networking (Web 2.0), Apple iTunes (including the iTunes Music Store), a Google office suite and more. These paradigms shift, expand, extend, or outright revolutionize application development. What happens then if we put Jeff’s application on an open source and standards-based diet? How do the feature requirements change?

“The application doesn’t need to share memory with other applications…”

I think the Web 2.0 answer to this is actually, why not? Social networking has proved a valuable asset in everything from retail to business (i.e. group rankings). Sharing and collaborating on data is becoming pretty common (i.e. Google Docs, Google Calendar). It’s not a far stretch to even apply real-time features such as text chat (or even VoIP). I’m pretty sure this wasn’t Jeff’s original direction, but I think it’s an interesting twist.

“Would need to get data out of an MS-Access database…”

The answer here from an AIR perspective is two-fold I think. In a connected application there are actually two data stores (at a minimum). First there’s the client data store, which in the case of Google Gears and Adobe AIR means a local SQLite instance. Jeff mentions that porting from MS-Access isn’t valid, which is fine. What would happen if it was valid? There’s a ton of tools around SQLite, so I think getting data from Point A to Point B would be pretty straightforward (the devil is in the details).

When it gets interesting is in the second data store, which is actually the data store we all pretty much take for granted today – the database on the web server. In fact, in an AIR mentality, the remote server data store would actually be the primary touch point. The SQLite client database would be used for offline and synchronization purposes. When you start putting data on a remote server and using local access for user-specific needs, you really start to open the door for the first point of collaboration.

“How do we generate the PDF…”

Not that we’re all squarely back on the server, let’s take a second look at that question. The first approach that comes to mind is ColdFusion 8 with its new PDF features. The second approach that comes to mind would be LiveCycle Generator, which is designed for exactly this purpose. It seems feasible that either of these solutions could expose themselves as services that take a list of document files, and returns a single PDF. In fact, Adobe offers a point service that enables exactly this feature.

We did say that we wanted to put the application on a open source and standards-based diet though, right?

If we wanted to stay true to the “web” we’d also have to consider HTML itself. HTML after all is designed for documents. HTML can display tables, and if Google Spreadsheets is any indication, can pretty reasonably accomplish 80% of the more common Excel use-cases. Any word processing content is obviously also a target for HTML. Did I mention that HTML is a first-class citizen in Adobe AIR?

That’s where it starts to get really interesting!

Adobe AIR also supports native file extensions (as of the AIR Beta), so you could save HTML, but put your own extension on it. When a file with your extension is double-clicked, the AIR application launches and displays that “document.” Now you’re talking about extending web technologies and standards to the desktop, which is exactly what AIR aims to accomplish.

I know that none of this falls within Jeff’s requirements, and I’m not trying to pick on him. I do however think that AIR applications require a different mentality. When we think about applying open source, web standards, Web 2.0 principles, and services-oriented architecture (SOA), a different type of application emerges. In this case it is one that potentially solves the problems, adds new value and runs across multiple operating systems. Go web, go AIR!

This entry was posted on Friday, June 22nd, 2007 at 10:47 am and is filed under AIR. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.