Flex 3 runtime-shared-libraries (RSLs) is a mechanism to reduce the size of your applications and thereby reduce the time required to download the application. Its not an architectural change whereas RSLs are just SWF files whose code is used as a shared library between different application SWF files.
An RSL is a stand-alone file that the client downloads separately from your application’s SWF file, and caches on the client computer for use with multiple application SWF files. Using an RSL reduces the resulting file size for your applications. The benefits increase as the number of applications that use the RSL increases. If you only have one application, putting components into RSLs does not reduce the aggregate download size, and may increase it.
Noticeable point is RSL’s are being shared across domain also. Please read further for details. There are two kinds of RSLs, Signed and Unsigned.
Signed RSLs are libraries that are signed by Adobe and may be stored in the Flash Player Cache, which can be accessed by applications from any domain. This means if your application is using a signed RSL, the RSL may not even need to be downloaded if the RSL is ready in the Flash Player Cache. The signed RSL may have been put into the Flash Player Cache by visiting another web site that was using the same signed RSL. Signed RSLs have a “sgn” extension.
Unsigned RSLs are normal SWF files and are not loaded into the Flash Player Cache. Instead, these RSLs rely on the browser’s cache to keep them from being downloaded. It may be a third party or your component to be shared across.
Specifying RSLs on the command line
To link RSLs on the command line, use the -runtime-shared-library-path option. To get help for compiler options, enter mxmlc –help list details at the command line. The output for the -runtime-shared-library-path option is as follows:
-runtime-shared-library-path [path-element] [rsl-url] [policy-file-url] [rsl-url] [policy-file-url] alias -rslp (repeatable)
The first argument of the option is the path of the SWC file (or an open directory that represents a SWC). The next argument is the URL of the RSL that will be used to load the RSL at runtime, followed by the policy file URL.
More than one SWC can be used as an RSL. This is done by adding a -runtime-shared-library-path option for each library. Here’s an example of a command that specifies two RSLs:
>mxmlc main.xmml -runtime-shared-library-path=c:\flex_sdk_3_beta3\frameworks\libs\framework.swc,framework_126.96.36.1997.swz,,framework_188.8.131.527.swf -runtime-shared-library-path= c:\flex_sdk_3_beta3\frameworks\libs\rpc.swc,rpc_184.108.40.2067.swz,,rpc_30.189225.swf
Specifying RSLs in configuration files
This example uses an application configuration file, main-config.xml, whose name is the same as the application but with “-config” appended. This file is automatically read by the compiler at compile time. If I didn’t name the file after the application, it would be necessary to use the -load-config option to get the compiler to use the configuration file. First I create the initial contents of main-config.xml by copying the RSL information from flex-config.xml. Then I modify the code from there. Here is the configuration file:
Take special note of the append=true on the runtime-shared-library-path begin element. This causes the entry to be appended to any existing RSL entries in other configuration files instead of overwriting them. From the command line, enter the same command as you did last time. Only this time, rpc.swc will be dynamically linked:
>mxmlc main.mxml –static-rsls=false
You can verify that the RPC RSLs are linked to the application correctly by running the application without copying the RSLs. You will see errors as before when the application attempts to load the RPC RSL.
If you later decide you want to statically link the application so you can debug the Flex framework code, just set -static-rsls back to true or leave it off the command line all together—since the value defaults to true.
see more details