Flash's ExternalInterface and dynamic loading

Grr, I lost the whole day yesterday fighting this up.  Flash (starting from version 8 I think?) has this magic ExternalInterface API, which is quite useful.  With it, you can define an API for your SWF that external JavaScript will be able to access (almost) as if your flash object was a JS object.  Also, using ExternalInterface you can call JavaScript functions from Flash.

Going quickly through how useful this is: basically I was playing with XMLSocket and wanted to be able to call it from JavaScript.  In fact I don't like Flash at all, but it has this amazing XMLSocket functionality, you know, something that JS should have provided, like, 12 years ago.  So because browsers' JS engines don't provide this utterly basic interface that any other client-side environment on the Planet has, I had to resort to Flash to play with it.

So I coded my very simple and invisible SWF, which only exports an interface to XMLSocket that I can use from JS.  I learned a few things and thought I'd write about my experiences here (before you flame my genuine lack of Flash knowledge, please understand that it's the second time in my life when I touch Flash and all I wanted was to get out of that IDE ASAP :D  I hate it.).

1. External interface doesn't work if your applet is really invisible.

   Or at least, that's my conclusion.  If I put width="0" and height="0" on the <embed> and <object> tags, bye bye ExternalInterface.  In fact, bye bye Flash—nothing seemed to work.

   So I had to resort on adding width="1" and height="1".  After this hack, everything worked fine in all but the most problematic browser of All Time (InternetExplorer).

2. External interface doesn't work in Internet Explorer unless you're loading the SWF during page load.

   It's pretty simple: my code uses a JavaScript widget library (that I'll eventually release).  In it I added a Socket communication object that relies on Flash's ExternalInterface + XMLSocket.  Because this object might or might not be used, it makes no sense to load the SWF during page load.  So I add the SWF later in a DIV, using innerHTML.

   I spent all day debugging this in Internet Explorer (while Firefox and Safari were doing just fine; I'm not sure about Opera yet).

   In order to make it work in IE while still not loading the SWF from the start, I had to create an IFRAME where I loaded the SWF—this time it registers the ExternalInterface alright.  I also couldn't play with making the IFRAME invisible (i.e. width=0, or display: none) — that won't work, you have to hide it differently (by i.e. positioning it outside the viewable area).

Back to basics

Isn't “old school” great?  I don't want to use Flash, but I have to because by default, browsers don't have anything that would allow me to open an arbitrary TCP connection.  Why?  The things you can do with XMLSocket are amazing—like, being connected to the server.

Some folks have imagined ingenious ways (Comet) to do this with existing infrastructure: because HTTP is a request/response-based protocol, it means that the server can't tell something to the browser unless the browser has requested that something.  So the nifty idea was to make an XMLHttpRequest (yay, AJAX!) from the browser, request that the server would not respond until it has something to say.  Like “incoming move from your opponent” in a multiplayer game.  That is called a “long lived” request, since the socket is open and the client waits for information, which the server will eventually send.  This looks pretty much the same as the good old select() to me, but hey—this time it's AJAX.

There are multiple problems with this approach, however—such as the fact that on some server platforms, such a request will uselessly block a server process.  Of course, then they invented “non-blocking IO”, which alleviates the problem.  Java has this (but I can't describe how much I don't like Java).

Then, the HTTP standard enforces a limit on the concurrent requests from a client to a server: the client can open at most 2 simultaneous requests.  This means that while your AJAX request waits for some answer, you can only do at most one other request to the server.  As you can guess—there are ways to work around this too.

Then, there's also an overhead for every request—such as a DNS lookup, a client-server handshake, etc.  This could never match the performance that an already open socket provides.

So what I don't understand is: why the heck don't we have plain old sockets?  So simple, so powerful, so old and proven—and yet we invent buzzwords to work around this limitation!...