Darron Schall posted the scoop on ExternalInterface on the OSFlash list. Basically it's an object that enables synchronous communication between the Flash plugin and JavaScript. The key point is it's synchronous. No fiddling with callbacks here: the Flash player will pause while the request is being executed. No fiddling with the SPLIFF technique (scripting, php, localConnection, a hidden iFrame, Flash and FlashVars): it's all done for you, serialization and all that. I call it 'le petit Remoting': it's done through XML instead of AMF, but you never actually write any of the XML yourself, much like you wouldn't write AMF manually. There's a bit of info on usage at the osFlash wiki.

The great thing is that while it's implemented as is for JavaScript communication, it could be implemented as well for projectors, using a gateway and a serializer/deserializer in Your Favorite Language. Darron writes:

What does this mean? It means we can now build an open source synchronous projector (akin to mProjector) if we wanted to. Heres some details: The communication is done via an event and a few methods. When you call this ActionScript line: result = ExternalInterface.call("TheMethod", "A sample string param..."); The ActiveX object will raise a "FlashCall" event and send you the event request as an XML string. The string will look like this for the above actionscript:

<invoke name="TheMethod" returntype="xml"><arguments><string>A sample string param..."</string></arguments></invoke>
 

In the event handler, you can then fire off your "TheMethod" in your C# (or C++,m or Python, or whatever is hosting the control), and then return some data back to flash. When you return data, you have to pass it back in the XML format as well, but you would call the control.SetReturnValue("string") method, where "string" would look like this:

"<string>This is a sample string being returned</string>"
 

The Flash movie will block until either the return value is set, or the event handler is done executing (i.e. you don't have to return a value if you don't want to).

You can also go the other way around. Read the details here.

Darron further suggests that we create wrappers for this for oft-used functions, a file API, communications API, email, whatever. Well that's just plain sexy. If ever a project like that should fly, I would suggest naming the package spliff.* in honor of the previous technique. I can almost hear it: "Why crash and burn with projector software when you can spliff and fly?"