We now have a good understanding of the safeguards provided by each security-sandbox-type. We've also seen that .swf files opened or loaded from remote realm locations are always assigned the remote security-sandbox-type, and that .swf files opened or loaded from local realm locations are assigned one of three local security-sandbox-types. Now let's take a closer look at the mechanisms involved in choosing between those three local security-sandbox-types. Each of the following three sections presents a scenario in which a developer uses one of the three local security-sandbox-types. Each scenario describes both the rationale for, and mechanism for choosing, each security-sandbox-type.
Susan is developing a calendar application, calendar.swf, to be posted on a hotel's web site. The calendar loads holiday information from an external XML file, holiday.xml. The application is near complete, so Susan needs to send it to her client for review. Even though calendar.swf will eventually be posted on a web site, the client wants to demonstrate it to a variety of people at the hotel. The client won't always have an Internet connection available during demonstrations. Hence, Susan sends both calendar.swf file and holiday.xml to the client.
In order to allow calendar.swf to load holiday.xml from the local filesystem
during the client's demonstrations, Susan compiles calendar
.swf with the
-use-network compiler flag ...