Flex 2 added a neat little feature which allows you to load Runtime Shared Libraries, from other domains. And since the browser caches these libraries in theory we could all point to a central set of Flex 2 Framework RSLs and users of your application would only have to download the RSLs the first time they went to an application which used them. Before I show you how to make this work, lets talk about the caveats… First and most important, THIS IS UNSUPPORTED BY ADOBE. While the Flex team is working on a better, more permanent solution to this problem, this is really a hack and despite the fact that I am using this in my applications, neither I or Adobe warranty or support the use of this in any way. Second, since there is no failover mechanism, until we find a better home for the RSLs, if you choose to point to my hosted RSLs, your application will be at the mercy of my web server. Third, if someone hacks my web server and uploads new cracked malware RSLs, or uses a man-in-the-middle attack to replace the RSLs in flight, then you (and I) have been p0wned. Fourth, I, James Ward, may have included modified Flex framework files which do bad things, like track user behavior/input and report them back to my server. While I promise I have not done this, if you choose to use these RSLs, you are putting your trust in my promise.
So despite the caveats, I still think this hack is sufficient enough for many applications. Flex engineering is really working hard to make this work for everyone. In the mean time what is outlined here may likely help you to dramatically reduce SWF size. Read on to find out how.
Quick Start
I’ve created 3 RSLs, a small one, with just the dependencies of mx.core.Application and a medium one with what I guessed were the 20 or so most commonly used components, and then a large one with over 30 other components. Each RSL does not include the contents of the smaller RSLs. So if you want to take advantage of this technique using the medium RSL, then you will need to use the medium AND the small RSL. Here is table with the information about the RSLs:
| RSL | Size | SWC | Linker Source | SWC Catalog |
|---|---|---|---|---|
| small | 106K | Download SWC | smallLinker.as | Catalog XML |
| medium | 160K | Download SWC | mediumLinker.as | Catalog XML |
| large | 141K | Download SWC | largeLinker.as | Catalog XML |
Once you have decided which RSL to use, follow these instructions:
1) Download the SWC for the RSL(s) you want to use from ws.jamesward.org
2) Fix your build path
2.1) If you are compiling via Ant or the command line, then specify your external-library-path and runtime-shared-libraries like:
flex2-sdk/bin/mxmlc \
-external-library-path+=build/framework-2_0_1_b-small.swc,build/framework-2_0_1_b-medium.swc \
-runtime-shared-libraries=http://ws.jamesward.org/framework-2_0_1_b-small.swf,http://ws.jamesward.org/framework-2_0_1_b-medium.swf\
-o=build/testHostedFlexLibs-medium.swf \
-file-specs=test/testHostedFlexLibs.mxml
2.2) If you are using Flex Builder then go to Project -> Properties -> Flex Build Path -> Library Path -> Add SWC -> [Enter or browse to the first SWC] -> Add all the SWCs you will be using. Then select a SWC’s RSL URL and select the Edit button. Change the Link Type to “Runtime shard library (RSL)”, set the RSL URL to the correct swf url on ws.jamesward.org, deselect the “Auto extract checkbox”, and then select the OK button. Repeat this for each SWC. When done, select the OK button to exit the Project Properties. Here is what my Build Path looks like:

2.3) If you are using FDS, then just add the SWC(s) to your flex/user_classes dir and update the runtime-shared-libraries accordingly in the flex-config.xml file.
3) Recompile your Flex app (if Flex Builder didn’t do this for you automatically) and the file size should be significantly lower!
4) One more caveat… You have to actually load your application from a web server for it to work. This is due to the Flash local OR network sandbox. Maybe someone can suggest a better workaround.
How It Works
This all starts with the Preloader. The out of the box preloader doesn’t support cross domain loaded RSLs. If you use my hosted RSL(s) then you don’t need to worry about this since it includes the patched Preloader. However, if you are interested in really knowing how this all works, or if you want to download the source code and play with it, then here is what you need to do. In order for your application to be able to use the classes in the crossdomain loaded RSL, the Preloader needs to specify the securityDomain for the loaderContext of the RSLs. So in the loadRSL function of my patched mx/preloaders/Preloader.as file I have:
loaderContext.securityDomain = SecurityDomain.currentDomain;
loaderContext.applicationDomain = ApplicationDomain.currentDomain;
The source code I use to build the RSLs is available on Source Forge. If you want to play with the code, then you will need to copy the Preloader.as from the Flex SDK’s source code, update the RSL loaderContext as noted above, and add the import for the flash.system.SecurityDomain class.
You can also see that I have a wildcard crossdomain.xml policy file on ws.jamesward.org which allows Flash player to load the RSLs no matter what domain the requesting application is hosted on. One quick note on crossdomain policy files, since I don’t think it is said clearly enough, and often enough…
DO NOT EVER PUT A WILDCARD CROSSDOMAIN POLICY FILE ON A DOMAIN IF EITHER OF THE FOLLOWING APPLY:
– THE DOMAIN IS USED FOR COOKIE BASED OR BASIC AUTHENTICATION
– THE DOMAIN IS ON AN INTERNAL NETWORK
Now about the small, medium, and large RSLs… For now I opted to use just three RSLs to keep it simple. I am using just simple linker classes and compc to create the SWCs, then expanding the SWCs to get the SWF, which is the RSL. You can see all this in the source code, specifically, the build.sh file. I have also guessed at the best way to organize the RSLs (as far as what classes go where), but definitely want to hear what others think.
Now the fun part… To prove this all works, first go to the test app on www.jamesward.org and watch as the RSLs are loaded from ws.jamesward.org. You should now have all 3 RSLs in your browser cache and if you now go to another test app on a different domain the application should load much faster since it only needs to load 72K instead of what would have been over 400K (my test app doesn’t use all the classes in the three RSLs).
The Future?
I’d really like to hear feedback if this is a viable hack for those looking to reduce Flex app size. Let me know if you plan to use this technique, or if you don’t, why? What should be different? Also, I think someone could further hack the preloader to support failover and md5 checksums. Any takers?
Thanks in advance for your feedback!


62 Comments
Hi Tuan,
You should consider using the new Flex 3 Framework cache to reduce the size of your application. If the user doesn’t have the Flex framework in their cache, then the first time the application loads it will need to download your application and the Flex framework RSL. But after that everything should load from cache. More info here:
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:Flex_3_RSLs
I hope that helps.
-James
“To prove this all works, first go to the test app on http://www.jamesward.org and watch as the RSLs are loaded from ws.jamesward.org. You should now have all 3 RSLs in your browser cache and if you now go to another test app on a different domain the application should load much faster since it only needs to load 72K”
The first test app took 14000ms and the second test app took 32000ms to load, and he was still loading all the libaries is there a problem with the crossdomain.mxml? Or do I miss something?
Hi Arno,
Wow. Thanks for pointing that out. It appears that I forgot to updated the application on http://www.thebetterside.com to match the one on http://www.jamesward.org so they were pointing to different versions of the RSLs.
Clear your cache and try it again. Let me know if it works better this time. Thanks.
-James
Fast response!
It’s working fine now. 19000ms vs 5000ms
I have a question:
I produced a SmallLinker, MediumLinker and LargeLinker like METAL describes. In Flex Builder I Add the SWC and give my own webpage URL (example: http://www.example.com/test/SmallLinker.swf) to the SmallLinker etc. I get this error “RSL error 1 of 3″
I have 4 files in the test folder now: MainView.swf, SmallLinker.swf, MediumLinker.swf and LargeLinker.swf. Is there something that I do wrong? And what?
Did you modify the Preloader to allow it to load RSLs crossdomain?
Oh… well my thought was that you didn’t have to hack that when it is on the same domain. I guess my thing is working now because I changed the libary url back to your .swf.
I have still one question: If I load your example “test app” I get a loader that shows that he is loading Libary 0, Libary 1 and Libary 2 if I watch my example I don’t see such a loader. Do I have to modify something to get that?
Hi Arno,
What version of the Flex SDK are you using? Also, make sure you are not overriding or disabling the preloader in your application.
-James
Hi James,
I have a question about how two web applications use the same RSL in another web application, these three web applications in a same web server(same domin). So how to compile the application with RSL, since I can not set the RSL URL directively, because in the compile period I don’t know the real contextpath(IP and port) of the RSL web application.
Hi Austin,
I’d recommend using the Flex Framework Cache which is part of Flex 3. It will make dealing with this much easier.
-James
What’s the problem with a wildcard crossdomain policy on an internal network? It’s needlessly flexible sure, but is there a real security concern doing this if there’s no internet access?
By putting a “*” crossdomain file on your intranet you are allowing malicious SWFs to make requests to your intranet on behalf of the user. So if a user is logged into an internal system and that system has a “*” crossdomain policy file, then a malicious SWF could do whatever it wants on that system – as that user. Pretty scary stuff.
-James
One Trackback
[...] A few days ago Metal pointed out to me in a comment on my blog that by using the SWFs inside a SWC, my RSLs are much larger than they need to be. Sure enough he was right. When you use compc to create a SWC, the SWF inside the SWC contains a lot of unnecessary stuff when used as an RSL. That stuff is necessary to create an application which uses the SWC, so don’t go ditching compc. Here is what you need to do if you want to have size optimized RSLs: [...]