Flex Article

Improving Flex application performance using the Flash Player cache

Understanding RSL basics

In this section I describe the information you'll need to specify a Runtime Shared Library (RSL) for Flex 3. The information includes references to two types of files: SWC files and cross-domain policy files. SWC files are Flex library files that contain one or more components implemented in MXML or ActionScript. All Flex library files are shipped as SWC files in the frameworks/libs directory. A cross-domain policy file is an XML file that provides a way for the server to indicate that its data and documents are available to SWF files served from other domains. Any SWF file that is served from a domain that the server's policy file specifies is given permission to access data or assets from that server.

To create an RSL for Flex 3, you need to include three pieces of information:

• Pathname of the SWC file
• URL of the RSL
• URL of the cross-domain policy file.

Once you have the information, you can choose to enter it in the Flex Builder GUI, in a configuration file, or on the command line.

If there is a problem loading an RSL, failover RSLs may be provided, so the RSL's URL and the policy file may be repeated. The most common reason to use a failover is for the case where a copy of Flash Player prior to version 9,0,115,0 is unable to download a SWZ, so a SWF file is provided as a failover. Another scenario that may warrant using a failover is when the RSL is located on a different server from the application and that server is not responding. Using a failover RSL, you can load the RSL from a different server.

The path of the SWC file is needed for two purposes. The first is to read the digests of the RSLs that are stored in the SWC, which will later be used for validating the cached framework. The digests used in Flex 3 are created using the SHA-256 hash, a standard encryption algorithm.

An RSL digest is taken from the SWC and compiled into the application. After the application reads an RSL from the network or local machine, it checks the digest to compare it against the expected digest stored in the application. If the two digests do not match, the RSL is not loaded into application memory and an error is displayed. The other reason for specifying a SWC is to ensure that all the classes in the SWC can be automatically excluded from the application as it is compiled, which reduces the application's file size.

The RSL URL and the policy file are specified in pairs. However, if you're entering the information on the command line, a policy file does not need to be specified in the last pair if no policy file is required to read the RSL.

Flex 3 comes preconfigured with the SWC library file (framework.swc) ready to be used as an RSL. The file framework.swc contains the code for the Flex framework and the components. To use it you just need to "flip a switch." This process is covered later in this article in the section, Specifying RSLs on the command line.

The flex-config.xml file is located in the sdk_install_dir/frameworks directory. Open it now and look at how it is configured:

<runtime-shared-library-path>
   <path-element>libs/framework.swc</path-element>
   <rsl-url>framework_3.0.0.477.swz</rsl-url>
   <policy-file-url></policy-file-url>
   <rsl-url>framework_3.0.0.477.swf</rsl-url>
   <policy-file-url></policy-file-url>
</runtime-shared-library-path> 

The <path-element> element specifies that framework.swc is the SWC to use. The <rsl-url> element specifies the URL of the RSL to load. The name of the RSLs vary based on the build in which they are created. In this example, the RSL is local but theoretically it could be located on another domain. If the RSL is located on another domain, you may need a cross-domain policy file to gain permission to read the RSL. By specifying a policy file, you don't need to rely on the default location of the policy file in the server's root. This allows a policy file to be located in a subdirectory that will limit the scope of the policy file.

The next element is another <rsl-url>, a failover RSL. This one specifies a different RSL to load in case the first RSL is not successfully loaded. If the primary RSL file loads successfully, the failover RSL will not be loaded. Notice that the unsigned RSL is set as the failover for the signed RSL. If the version of Flash Player being used to run the application is not able to load signed RSLs, the signed RSL is skipped and an unsigned RSL is loaded instead. This ensures the application will still be able to load the RSL even if Flash Player 9,0,0,115 or later is not being used.

Page 3 of 6

Previous Page

Next Page