Deploying RSLs in Flex

RSL’s?  Runtime Shared Libraries are a technology that was introduced in Flex 3.0 that allowed our Flex applications to load much, much quicker.  What they really are is the shared libraries that we deploy for ALL of our applications (like the Flex Framework and common controls, or the data visualizations) in a separate download for the end user.  The end user will store these common libraries in their player cache after they have been first downloaded.  This means that they will "never" have to download those bits again.  Your 600k Flex application all of a sudden went to a 200k app with a 450k framework download.  However, the next time a user visits your site, they only need to download the 200k app, since the framework will already be on their PC.

Sounds like a good deal, right?  If you use the official Flex 3 builds (http://opensource.adobe.com) then this code is digitally signed, and there is essentially no penality in deploying this bandwidth saver. The nice thing too is each version of the framework that the user downloads is stored separately, so you know that if you target your app for a specific Flex 3/4 SDK, that the user will always have that version.

Who should not use RSLs? Anybody who monkey-patches the framework, or has their own build of the SDK should NOT use RSLs.  Everybody else pretty much should.   If you don’t know what that means, then you’re OK :)   RSLs also up the requirement of the Flash player to 9.0.115, rather than 9.0.0, which may pose a problem for a few people that haven’t upgraded in a very long time.

How do you enable it?  That’s pretty simple too!   All you have to do is right click on your Flex Builder project, and go to the properties menu option.  Click on the Flex Build Path node, and then the Library Path tab.  Change the Framework Linkage from "Merged" to "RSL".   If you don’t want to customize your deployment, that should be all you have to do.

By default, you will be able to deploy your app with any signed bit of code as an RSL. This includes the Framework, the RPC code, and the Data Visualization code.  You can customize this by deploying unsigned RSLs, of your own code and modules.  This means that certain modules can be separated out and stored on the user’s machine as well.  Open the node of the code that you want to enable as an RSL in the Library Path tab, and click on the Link Type node.  Click on Edit… to change the link type.  In the resulting dialog box, you should be able to change the link type to RSL. You can also choose to deploy the code as a trusted cache (which means that as long as that the SWF’s filename will be used as the verification), or you can enable Digest mode, which is essentially a CRC check on the SWF to make sure it is the right version.  I would suggest Digest mode (although there is a very, very small processor penalty to enable it).

So, now you’ve got your project setup for RSL’s, how do you deploy it? You can deploy this project just as you would any other project — by coping over the SWF files to your web serer.  The only difference here is you will need to copy a few other sets of files.  In your release directory (after you export a release version of your code), you should now see additional files for every RSL enabled bit of code you setup.  For example, your framework will now show
framework_3.0.build_number.swz in addition to your normal SWF output.  Make sure these files end up on the web server as well.  You will see SWZ files for signed bits of code, and SWF files for unsigned bits.

In my own setup I did run into one issue when I was moving my app into production.  Apparently recent versions of IIS won’t serve files that don’t have MIME-Types associated with them.  After deploying my app to the server, I was getting RSL Digest Error displayed in the the browser when I was deploying.  The problem was I was not the one seeing these errors, but rather my customers.  Because IIS didn’t have a mime-type setup, it would give 404 errors for the SWZ files for those people who hadn’t downloaded those files. To fix the issue, add a new mime-type of x-shockwave-flash associated with the .swz file extension.  Things should work then.

Enjoy your faster downloads!