This task is quite strange: I needed to find a way how to execute existing ActionScript code on a headless Linux server. A scenario like this can also happen if you need to develop an automated test environment for you Flash / Flex or AIR applications. You cannot run either Flash SWF files or AIR applications on a headless server, as both need graphics output always. Even in the case of an AIR application that shows no window at all. In Linux terms, a running X server is always needed. Otherwise, an AIR application throws the error “Gtk-Warning **: cannot open display:”.
There are multiple discussions in the Internet how to solve this (e.g. here and also here in the Adobe forums), and they agree that the only solution that is currently feasible is to use Xvfb for mimicking an Xserver (or alternatively, the same approach with VNC). See the first solution below for that; but I also discuss all the alternatives I looked into.
Xvfb to mimic an X server (the only working alternative in this article)
Xvfb is a “virtual” X server, granting an X server interface to application, but doing all the calculations in memory. You do not need and physical input devices or screens attached to the machine for this.
There is one problem with the Xvfb solution, however: “which is that AIR is not currently recommended by Adobe for headless server-like applications. As I understand it, there could be cases where the runtime popped up a confirmation dialog, and some things about the app might not work correctly until you remoted into the server to dismiss the dialog.” [source]. See also a comparable statement here.
We can get around this by designing the AIR application so that a new process is started for every request (while the X server stays running all the time, and the AIR processes connect and disconnect with it). This has some performance penalty, but works around the problem that a server-like (port listening) AIR application has with the above “confirm the popup” thing.
The task to deploy and run an AIR application this way on a headless server is a project of its own, and I have written about it separately.
Tamarin to run ActionScript bytecode
Now the restriction is that only ActionScript code could be executed server-side. Which means that code that depends on the Flash, Flex and AIR runtime libraries could not be executed, as these runtime libraries are native and closed source, not included in Tamarin. So the code that can be executed in Tamarin is quite limited and useless, as there would be no way to communicate with its environment. To solve this, some ideas come to the mind:
- There would be the option to create own ActionScript classes with a native implementation, adding them to Tamarin, which then would enable the required features for communicating with other pieces of software, like writing files etc..
- In extension of this, perhaps the Merapi Java / ActionScript bridge could be used together with Tamarin.
- Perhaps there is the option to extract the runtime libraries from Flash player or the AIR installation, but this is quite heavy hacking, and not apt for redistribution because of Adobe licencing restrictions [source]. Probably it is enough to not call any part of the library that depends on graphics output (as such calls result in errors without X), but perhaps it would be required to only extract those part of the runtime libraries that do not depend on graphics output (as we want to get around this very requirement here).
Custom AIR launcher
This is some serious AIR hacking, and not apt for redistribution because of Adobe licencing restrictions [source]. It might be possible to create a new AIR launcher that includes the AIR runtime DLL as an in-process shared library (outlined here). But again, exactly this runtime DLL would still need a running X server. So again, probably it is enough to not call any part of the library that depends on graphics output (as such calls result in errors without X), but perhaps it would be required to only extract those part of the runtime libraries that do not depend on graphics output (as we want to get around this very requirement here). At least the dependency of the launcher from X would be removed that way (guessing that it is the launcher that checks if X is running).
The headless Flash player Ichabod together with Merapi
Merapi is not only able to connect Java with AIR applications, but also with Flash / Flex applications that run in the Flash player. Together with the headless Flash player, this would be a quite elegant solution.
The problem is, the headless Flash player is not publicly available. It is called Ichabod and reportedly used by Google to index Flash content [source], but apart from this and perhaps some very few other customers, nobody has access to it. There is a feature request for a headless Flash player here, but it is still open. See also this article about the Ichabod rumors.
As the normal Flash player needs also an X server, there is no way to resolve that dependency here. Merapi is of no additional use here.
haXe to run converted ActionScript code
The programming language haXe is quite similar to ActionScript, and can compile to native code, among other things. This opens up the option to to convert ActionScript applications to haXe applications, which then run without a dependency on a X server.