Adobe AIR on Linux: Pre-Beta Testers Needed

Adobe AIR is a cross-operating system runtime for deliverying rich Internet applications on the desktop. Developers using Flex, Flash, HTML, JavaScript, and Ajax can easily build applications for the desktop using Adobe AIR. As of today there have only been releases of Adobe AIR for Windows and Mac but Adobe is committed to also delivering a version for Linux. This is great news for developers like me who use Linux as their primary desktop operating system. The Adobe AIR team is now in the phase of development where they need a handful of additional testers to begin testing initial builds of AIR on Linux. If you are interested please answer the questions below in an email to helptesterairlinux at adobe dot com.

1. Are you comfortable working with prerelease software that is not yet feature complete?

2. Will you be able to submit bug reports on issues that you find back to our development team?

3. How many hours a week can you spend testing on Linux?

4. What is the primary distribution of Linux that you’re using? If you are using more than one distribution, please list.

5. Will you be developing applications on your Linux machine (as opposed to writing on Windows and testing the applications on Linux)?

6. What other operating system are you using, if any (Mac, Windows)? Can you compare the behavior of AIR for Linux with AIR for Windows and AIR for Mac OS?

7. Are you working on an AIR application today? If so, please describe.

8. Are you primarily a Flash, Flex or JavaScript developer?

9. What is your name, company name and email address?

Unfortunately at this point not everyone will be accepted into this pre-beta program however there will be public betas when the pre-beta has been sufficiently tested. And at that point maybe we will finally know whether penguins can fly when given AIR.

What is a Rich Internet Application?

The more software experiences become like the natural world the more users are pleased with those experiences. One of the most powerful, understandable, and universal concepts in computing is the idea of a desktop containing files and folders. Users embraced this metaphor in their software because it modeled their natural world experience.

There is a paradigm shift underway. In this shift, developers are creating user interfaces which more closely model the natural world. Since 2002, the term used to describe these types of software applications is “Rich Internet Applications”, or RIAs. Technologies like Ajax, Flex, Silverlight, Adobe AIR, and JavaFX are growing in popularity as this shift to RIAs gains momentum.

But what is an RIA? Answering that question is like trying to answer “What is a tree?” You may be able to identify an RIA or a tree with certainty when you see one, but coming up with an exact definition can be very difficult. In cases like this, the best one can do is to identify some of the fundamental characteristics that the term encompasses.

When you break down the phrase “Rich Internet Applications”, you find that “Internet” and “Applications” are well understood. It’s the “Rich” aspect that makes RIAs interesting, and it’s the “Rich” aspect that requires a fuller explanation. Essentially, a Rich Internet Application is capable of delivering a rich experience to the user. It is the richness of the experience that is often enhanced by making software that is more natural – more connected, more alive, more interactive, and more responsive.


We are all connected. On this relatively small planet we all have many things in common. We communicate with one another via many different methods, in many different languages, sometimes easily and sometimes with difficulty. Likewise RIAs are built on a network that connects us all – the Internet. RIAs use this network of billions of connected pieces to help us communicate – between each other and between systems, sometimes easily and sometimes with difficulty. And like each of us, in some scenarios RIAs need to be able to work when disconnected from the Internet.


Movement and the passing of time are critical to our experience of beauty and the emotional reaction we have to it. Watching waves continuously crash on a beach is an experience which fills us with life. Similarly, we would not sit and watch a beautiful sunset for very long if it never changed. In RIAs, we create rich experiences by modeling the movement and beauty we find in the natural world. Smooth sliding transitions, zoom effects, soft blurs, drop shadows, and rounded corners are elements of RIAs which help make software feel more like the natural world. Beauty is often simple and never overdone. Software that feels more alive evokes an emotional response from us. That emotional response can help to improve our overall satisfaction with the software. RIAs should feel alive.


When people communicate they interact — sometimes physically, sometimes audibly, and sometimes visually. Interaction is how we transmit and receive information. The richness of an experience is heavily dependent on this interaction made possible by our senses. RIAs facilitate physical, audible, and visual interaction. Many new devices are allowing for more natural methods of physical interaction. Multi-touch interfaces like tablet PCs and media players are becoming more common because users want to interact with software like they interact with objects in the natural world. Many more software applications are also adding video and audio capabilities, and some of these applications support bi-directional multimedia interaction. This allows users to interact visually and audibly in the context of an application. Imagine filling out a form online and, if needed, being able to interact via webcams with someone who can help you complete the form. Applications which embrace interactivity to that level are helping to bring natural world interactivity to software experiences.


In the real world when people interact with each other or with objects like rocks and trees, those things typically respond quickly. If I kick a rock it immediately moves, unless it’s a big rock in which case my foot immediately hurts. If someone speaks to another person they expect a timely response. At a baseball game, you can see scores whenever you want, just by looking in the right place. Too often in the world of software people are forced to wait for their computers to respond. Whether due to network connectivity issues, processing limitations, or other problems, software too often makes us wait. Most web applications leave users waiting for at least four seconds every time the user clicks on something. With many applications the wait times can be significantly longer, even on a broadband connection. Imagine what an everyday conversation would be like with that latency. Real-time streaming, high performance client side virtual machines, and local caching mechanisms are becoming in integral part of RIAs because these technologies reduce latency, increase responsiveness, and make software feel more like the natural world.

Natural Software Experiences

All kinds of software applications — from ERP business applications to word processing applications — are embracing the characteristics of what we now call Rich Internet Applications. This move is happening because users intuitively want to experience software like they experience the natural world.

Rich Internet Applications are proliferating because they are more connected, alive, interactive, and responsive than yesterday’s software. In ten years nearly all software will be what today is called a Rich Internet Application. But in ten years it will be only natural to just call it “software”.

Flex & Ajax Developers: 8 Days Left to Win a $100,000 Vacation

Step 1) Build a kick-a AIR application with Flex and/or Ajax
Step 2) Submit it to the AIR Developer Derby contest
Step 3) ???
Step 4) Profit!

Unfortunately I can’t participate because I’m an Adobe employee. But I wish you good luck and if you win please let me know if you need a travel companion (or 2 because we should take my wife too). :)

Census RIA Benchmark Updated with GZip and Laszlo

I’ve just posted the newest version of the Census RIA Benchmark application which compares data loading via various methods in Ajax, Flex, and now Laszlo. When I first began talking about the results of these benchmarks and heavily advocating AMF for large data sets some people suggested that my results were flawed because I wasn’t using gzip compression on the text streams. I have always wondered how many people actually use gzip but these critics seemed to indicate that everyone was using it. Based on some past experiments I postulated that AMF would still be significantly faster than using gzip. There is a trade off when you use gzip. The amount of data that has to cross the wire is significantly smaller but there is increased latency on the server to do the gzip and on the client to ungzip. Sometimes this trade off is worth it. Unless you are using AMF. AMF uses a very basic form of compression that is extremely fast, faster even than just creating XML or JSON strings. And of course much faster than creating big strings and then compressing/decompressing them. Now there is definitive proof of this. AMF is still by far the fastest method for loading large data sets in RIAs. Not only is it faster for loading the data, Tamarin makes client-side operations like sorts and filters extremely fast. All of this is evident if you spend some time with the Census application. Check it out and let me know what you think.

For this version I’ve added a Laszlo test. Sometimes people ask what the differences are between Flex and Laszlo. This was my first time building anything with Laszlo so I won’t comment on the differences in programming models since my views are probably skewed after spending three years with Flex and only a few hours with Laszlo. But two significant differences between Flex and Laszlo can easily be seen in the benchmark. First Laszlo doesn’t use AMF3 that I know of. Let me know if I am wrong about this so I can update the test. Also Laszlo does not yet compile to Flash 9 bytecode so Laszlo applications are not able to take advantage of the Tamarin virtual machine. Beyond that I really don’t know much about the differences. If anyone that reads this has used both it would be great to hear about your experiences. Just please don’t tell me that Laszlo is better because it has multiple output formats. Tell me how this or other features have made a difference in what you have built. Also since this was my first attempt at building a Laszlo application I may not have done everything correctly. So please take a look at the source code and help me make it better and more accurate.

I hope that you find the Census RIA Benchmark application helpful. Please let me know if you have any feedback about it.

Ajax and Flex Data Loading Benchmarks

For close to a year I’ve been working (in my infrequent spare time) on an application that shows differences in data loading for RIAs (Rich Internet Applications), comparing Ajax methods, Ajax frameworks, and various Flex methods. The results are pretty surprising. The screenshot below is from a test run I did with the server running locally. (Note for the screenshot below: All tests except Dojo were 5000 rows, while the Dojo test was 500 rows.)

To run the benchmarks yourself, go to:

I have tried to be as fair as possible with these tests. Still, I encourage you to use these results only as an initial guide. You should always do your own benchmarks that more closely resemble your actual use case.

You can find more details explaining the tests and the results inside the “Guide Me” mode of the application, so I won’t go into depth here. Also, the code is Open Source (GPL) on SourceForge. If you feel that a test should be done differently or you find other things that you think should be changed, get the code, fix it, and send me a patch file. Please don’t just tell me I did something wrong. In the spirit of Open Source, help me fix it. I want this application to be as fair and accurate as possible.

While these results may be eye-opening to some, once you understand some fundamental differences between Flex and Ajax, they end up making a lot of sense. Flex applications run within the Mozilla Tamarin VM inside Flash 9. Tamarin does JIT compilation which makes code execution 10 to 1000 times faster than interpreted JavaScript in the browser. Also Tamarin can be very efficient when dealing with typed objects.

In addition, Flex supports a compact binary object serialization protocol, called AMF3, which is extremely fast. There are numerous Open Source implementations using various backend technologies for AMF3, as well as a commercial / supported Adobe product, called Flex Data Services. If you control both sides of the wire in your application, then there is rarely a good reason to serialize and deserialize text. Objects are blazing fast as you can tell by this benchmark. AMF3 is also typically much more efficient across the wire (even without compression) and consumes much less client side memory. JIT compilation and binary object serialization are the primary reasons why Flex AMF3 is so fast, even in the test with the full 20,000 rows. And, it’s not just faster for loading – it also speeds client side sorting and filtering. (Try client-side sorting in the Dojo benchmark and the Flex AMF benchmark.)

A quick note on compression: I did not include compression support in this version because its value really depends on many application-specific factors. For instance, if most of your users have slow connections then compression can help speed things up, but if most have fast connections the added latency can actually make things slower. However, I do want to add a Gzip option to this benchmark for the next release.

This is really a version 0.1 release. There are many improvements I have on the to-do list. And I’d love the community’s help. Here are some things I want to do for the 0.2 release:
– Add Gzip option on tests
– Add a Laszlo test
– Implement more Ajax frameworks that have DataGrids and that support paging and sorting
– Add a server side sorting option
– Add Ajax client side memory usage metrics (don’t know if this is possible)
– Improve the UI for use on projectors (I use this demo in every presentation I give)
– Integrate feedback I get from the initial version
– Maybe add a WPF/E test (which I won’t be able to do because I run Linux)

I sincerely hope that you find this demo useful. I built it as a tool to help people learn more about the various methods of data loading in RIAs. I did not in any way build this to attack Ajax, Dojo, and SOAP. Please help me improve this application so that we all continue to learn more about the technologies available to us.