Scripting your Flash applications …

As someone of you may know, I really like studying programming languages and sometimes implement for fun (or for work) simple scripting languages that help me out during development.

The fight between scripting and programming languages will probably never end. Well, it is not really a fight but more an infinite race where the first position is exchanged continuosly between the two participants.
We need flexibility first, and so we add to our complex applications a way to support scripting to be able to easilly perform changes without the need to run the long time taking compilation process a low level language might take; then, the more the scripts became complex, the more we need an increase in performances, and so we rapidly move to compiled plugin egines; plugins offer a bit of flexibility and usually a good speed. Then we grant other users the permission to write plugins and so we need a sandbox to run the plugins in and to be sure every single line of code that is executed doesn’t harm our application. And so we revert back to scripting … and so on.
The race will never end but the technologies will continue to increase in speed and sometimes in complexity.

All the introduction is to say that its not the point to choose if scripting is useful or not for Flash applications, but to say that someone might need it for reasons we cannot think about right now, and someone else might not need it because they are fine with recompiling everything from scratch at each single small change.

I don’t think there are some many Flash applications that support scripting. I built myself a few of them for my company but they are for a particular purpose and probably the same motivations that made me decide to implement a scripting language are hard to find for other kind of applications.

As far as I know, the most of the applications that need to be flexible use a plugin system (more or less complicated – as Aviary for instance and Hobnox) and are fine with it because – we must say that – ActionScript is itself a scripting language and a SWF file is nothing more than a bunch of instructions (more or less) generated by compiled ActionScript.

But sometimes security comes into account, and it is hard (even if possible) to limit the funcionalities used by a plugin if this plugin is created by a 3rd party developer.

And so it comes into account scripting. With scripting we have full control over what a developer can do an how he can do that. We can limit it, provide builtin functionalities … But everything costs something, and building a fast/flexible/powerful/useful scripting languages is not that easy as it might seem.

This is why I decided to spend a bit of time in explaining the basics to implement a scripting language in actionscript to be able to script our applications. I’ll walk through all the passes – from lexing to bytecode generation and maybe a quick look into Virtual Machines – with the aim to provide someone (maybe in the far future) a bunch of documents to use as reference to build their own scripting language.

I’ll try to give an in depth look, but as far as the argument is quite complicated and full of facets, you may not find here the right solution for you. Nor the fastest or the most flexible. But it is better then nothing so if you are interested in that keep reading the blog 🙂

New Flash Player security rules

Erica Norton of the Flash Player Team wrote an interesting post in the flashcoders list about the upcoming changes in the Flash 8 security restrictions.
I’m copying here parts of that post:
(cut)
In Flash Player 8, the rules are:

  • local with file system content may only communicate with other local content
  • local with networking content may only communicate with remote content
  • trusted content may communicate with both local and remote content

(cut)
The first 2 types will be publishable. For those that do not upgrade their Authoring tool, we will be providing a command line utility to convert SWFs to local with networking SWFs (and vice versa).
There will be 2 mechanisms for trusting content.
The first, many of you have seen: the Settings Manager. The second method is in the form of .cfg files placed in a specific location for the Flash Player to read.
This will enable distributors of local content, via an installer for example, to install a .cfg file to the appropriate location, thereby trusting the content. One could also provide an updater to an already distributed bit of content in order to trust those documents this way.
Please note, that one may trust a directory, which trusts all content recursively below that directory.
(cut)
There will also be an API available in ActionScript in order to detect which of the 4 sandbox types that the SWF is (remote or local: local with file system, local with networking, trusted) so that in ActionScript you can do one thing or another.

http://chattyfig.figleaf.com/pipermail/flashcoders/2005-July/145237.html