WikiPage Marshall Plan modified by SourceForge Editorial Staff

SourceForge Editorial Staff — Thu, 15 Mar 2012 18:12:58 -0000

# Marshall Plan **MOST UP-TO-DATE DOCUMENT: [draft of official documentation](http://blogs.adobe.com/flexdoc/loadingSubApps.pdf)** **The draft document below was locked in time as implementation of the Marshall Plan began. It may not reflect the final implementation choices, but serves as an accurate overview of the problem we're solving and how we intend to solve it.** ## Overview The "Marshall Plan" is the nickname for the SDK feature to support cross-versioning. The nickname comes from the aspect of the feature that uses shared events and/or the SandboxBridge to marshal objects across ApplicationDomains. Marshalling was popularized in Windows as a way of transcoding objects so they can be shared between applications in different address spaces. We intentionally mispell "marshal" as Marshall to draw reference to the famous "[Marshall Plan](http://en.wikipedia.org/wiki/Marshall_Plan)" that helped define a post-WWII Europe. We hope this "Marshall Plan" will define a post-3.2 Flex that liberate our developers from having to have all of their code compiled by the same version of Flex. The Marshall Plan will also implement, or lay the foundation for implementing, untrusted application support in Flex. Today, all Flex SWFs loaded into a Flex application must be loaded into the same SecurityDomain. This prevents or inhibits the development of portal-type applications because if the portlet is hosted on a separate server and is loaded into the same SecurityDomain, it can no longer access resources on that server. Also, once loaded into the same SecurityDomain, a "bad" application can access data and objects in the host application and potentially steal information such as passwords. A Flex 3.0 or earlier SWF loaded into a different SecurityDomain will throw exceptions as the SecurityDomain disallows access to the Stage and other resources the main Flex Application can access. Thus, the Marshall Plan is really two things: * Cross-Versioning Support: SWFs are in the same SecurityDomain but different ApplicationDomains and may have been compiled by different versions of Flex. * Untrusted Application Support: SWFs are loaded into different SecurityDomains and cannot access the main application or the Stage and other restricted resources. ### Why Cross-Versioning? In most applications, even very large applications, the entire base of source code is recompiled before release. This is true of virtually every desktop application shipped by Adobe (Flash, Photoshop, etc). This ensures that all pieces of the application are using the same version of the APIs. Thats because in Windows, a mismatch between the APIs used by the caller and the APIs expected by the callee results in a run-time exception and the application crashes. In other application development environments such as Java, significant effort is made by the Java team to ensure that no APIs were modified. This generally allows an application developed against one version of the Java APIs to run against a newer version of Java. The few cases where APIs cannot be made to be compatible are well-documented. The task of improving APIs, fixing bugs and adding new features without breaking API compatibility is made easier in Java due to the ability to overload functions. You can add new parameter lists to functions while keeping the old ones around. That bloats code size, but Java apps are generally not worried about size. In Flash, the SWF has a version "stamp" that informs the player as to what versions of APIs to support for that SWF. The player carries extra code for legacy APIs in its download. Actionscript APIs are not versioned. We could add a version parameter to every API, but that would not allow us to use getter/setters which have a fixed parameter list, and we'd end up carrying extra code for legacy APIs. Because Actionscript does not support function overloading, and we don't want to add version stamps to our APIs, Flex is much more restricted on how it can change APIs from version to version. With additional pressure to become a more lightweight framework going forward, it is impossible for us to maintain code for legacy APIs. We must either make very few changes, or find a way to isolate developers from those changes. A few very large, and highly important applications are not recompiled for every release, mainly because they are not always developed by one group of developers. That is because they are more like Portals where pieces of the application are developed independently and asynchronously by third parties. The classic example is a form-based application like Adobe LiveCycle Workspace. Anyone can develop new forms to go in the Workspace. If the main Workspace shell is updated, it is essentially impossible to go find all of the contributors of custom forms and get them to update as well. Thus, it is imperative that Flex be able to support development of applications where not all of the pieces are compiled against the same version of Flex, yet we don't want our hands tied down by compatibility issues if possible. ### History of Cross-Versioning Support in Flex The need for Flex to support cross-versioning was seen way back in Flex 2. In Flex 2.0.1, a cross-versioning scheme was implemented, but never officially documented. It involved the Singleton class, a bootstrap loader, and modules that shared definitions in the bootstrap. As 3.0 neared completion, testing Flex 3 applications loading Flex 2.0.1 modules was found to be completely broken. APIs in the classes that needed to be in the bootstrap loader had dependencies on classes that could not be in the bootstrap loader without causing compatibility problems. It became apparent then that the "shared definitions" strategy was extremely fragile. Not only did it require a detailed understanding of ApplicationDomains and class dependencies, it required that all developers understand the bootstrap mechanism and not make API changes that would violate the bootstraps dependency requirements. ### Marshall Plan Overview It was decided that the safer approach would be to load SWFs compiled with different versions into separate ApplicationDomains and have them interoperate through event passing. That is the essence of the Marshall Plan. Instead of Forms as modules loaded by ModuleManager, each Form must now be a separate Application loaded by SWFLoader (modules require class-level interdependence). Each sub-application will be loaded into separate ApplicationDomains. Where there needs to be interoperability, the code in each ApplicationDomain will communicate via shared events. A typical place where there needs to be interoperability between pieces of an application are features supplied by our manager classes, such as PopUpManager. In the broken module-based cross-version design, all of our Manager classes were broken into two pieces, a Manager and an Implementation. Each piece of the application would call to the Manager and it would ask the Singleton for the Manager's Implementation. The main application was responsible for making sure the latest version of the Implementation had been registered with the Singleton so that version of the Implementation would service the Manager's API regardless of which version of the Manager was used to call the Implementation. In such a design, not only did the API have to remain unchanged, but the behavior had to remain unchanged as well. That's why that design was overly restrictive and fragile and ended up broken. In the Marshall Plan, each piece of the application has its own instance of the Manager. However, if the Manager in the sub-application needs to perform a task only the top-level application's Manager can perform, it will communicate to the top-level Manager via shared events. The Manager's APIs can change from version to version as long as the events used to communicate between versions remains untouched, which is much easier to maintain and less restrictive. The events will be versioned as well, so we can support or deprecate interoperability with extremely disparate versions of Flex in the future. The Marshall Plan will be the only official cross-versioning support mechanism in Flex. The Marshall Plan will only support 3.2 Flex applications working in Flex 4 and beyond. There will be no support for Flex 3.0 or Flex 2.x applications working with Flex 3.2 or later. Folks requiring cross-versioning support in the future must upgrade all existing applications to Flex 3.2 or later. ## Technical Description The key pieces of technology in the Marshall Plan are * flash.system.ApplicationDomain * flash.system.SecurityDomain * flash.display.LoaderInfo.sharedEvents Relevant, but not currently used are: * flash.display.LoaderInfo.parentSandboxBridge * flash.display.LoaderInfo.childSandboxBridge A better understanding of Flash Player Security might be useful. See [http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf](http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf) ### Sub-Applications vs Modules The Marshall Plan is designed to allow an application that consists of a main application and a set of sub-applications to consist of sub-applications that are compiled with a different version of Flex than the main application, and/or prevent an untrusted sub-application from gaining access to information managed by the main or other sub-applications. The Marshall Plan uses ApplicationDomains and SecurityDomains to separate the sub-application from the other sub-application and main application. However, once the sub-application is in a separate ApplicationDomain or SecurityDomain, certain operations that require that information be shared between applications no longer work and must be approximated in some way. Applications consisting of a main application and a set of modules will not be supported as modules require a child ApplicationDomain topology ### Impact of Application Domain The main goal of the Marshall Plan is to allow a main application and trusted sub-applications to be compiled with different versions of Flex. This means that the main application and all sub-applications must be loaded into the same SecurityDomain, but separate ApplicationDomains. In such a configuration, the only additional restriction placed on the applications is that they cannot share class definitions not defined in the player. When passing an object from one application to another, it can be handled in the receiving application as a flash.display.Sprite, but not an mx.core.UIComponent or mx.core.IUIComponent. If a UIComponent is passed, tests in the receiving application such as (obj is UIComponent) or (obj as UIComponent) will fail, but access to properties on UIComponent via obj["measuredHeight"](%26quot%3BmeasuredHeight%26quot%3B) will work. Access to properties via obj.measuredHeight will work if obj is of type Object, but if obj is of type UIComponent, there will be a coercion error as obj is assigned. Even if a UIComponent is passed, if obj is of type Sprite, tests such (obj is Sprite) or (obj as Sprite) will succeed, and access to properties such as obj.width, or obj.parent will work. ### Impact of Security Domain The secondary goal of the Marshall Plan is to allow a main application to load untrusted sub-applications yet allow for some interoperability between applications. The allowed interoperabilities are described in the next section. Untrusted applications must be loaded from a different domain or sub-domain than the main application. This means that it will not be possible to test this configuration directly from FlexBuilder as the untrusted applications must be deployed to a server. When an application is loaded into a separate SecurityDomain, not only does it have a separate ApplicationDomain, but additional restrictions are placed. While some of those restriction can be lifted, removing those restrictions basically institutes a level of trust. The Marshall Plan will assume that none of the restrictions has been lifted, though it will respect allowDomain settings. The additional restrictions are: #### Stage All access to the stage (except setting stage.focus) throws an exception. The entire Flex Framework must be examined for dependency on access to the stage and either eliminate that dependency, or fail gracefully if the exception is thrown. #### Mouse Mouse event listeners in one application cannot pick up mouse events from another application even if using bubble or capture phases. Normally, component code is not interested in mouse events outside of the component, but there are situations where they do need those events and those places must be found and modified to use the Marshall Plan protocol to get enough information about mouse events in the other applications in order to handle the situation successfully, but without knowing too much about what is going on in the other application. #### Pixels Code in one application cannot access the pixels drawn in another application. The Framework should not have any functionality that requires pixel access. #### Properties Code in one application can access many of the properties in an object from another application if that object is shared between applications. As in the separate ApplicationDomain scenarios, strong-typing cannot be used, but dynamic property access will work in most cases. However, sharing objects between applications that have references to other objects in the source application is considered a security violation. No objects shared between SecurityDomains in the Marshall Plan code should have any reference to any other object. A few properties are restricted. You cannot access the Stage as mentioned earlier, and you cannot access the parent of any DisplayObject instantiated by another application. This means that the Marshall Plan code will implement different code paths in certain scenarios and handle interoperability differently depending on whether the sub-application is trusted. ### Impact on Flex Classes The Marshall Plan implementation must address all places in the Flex Framework affected by the restrictions of separate ApplicationDomains and SecurityDomains. We must identify all places and patterns in our code that provide interoperability between applications and sub-applications when in a child ApplicationDomain configuration, and decide whether to fully emulate them despite those restrictions, partially implement them, prevent them, or implement them differently. One of the patterns is the "mouse up somewhere" pattern. This pattern is usually implemented by attaching a listener or two to the stage to catch all mouse up events. The stage is not accessible from a different SecurityDomain and thus our code needs to be modified to handle that situation. Code that drags objects around (Panel title bar, Slider, ScrollBar thumb) are common uses of this pattern. #### SWFLoader SWFLoader houses the flash.display.Loader that loads the actual content in another ApplicationDomain or SecurityDomain and contains the LoaderInfo whose sharedEvents dispatcher will be used to communicate between the two SWFs. SWFLoader may also have a property added to it to make it easier to specify that the SWF should go in a separate ApplicationDomain. #### Panel The code in Panel that allows the user to mouseDown on the title bar and drag the panel must be modified to handle being in a separate SecurityDomain. #### Button Button has code that restores the "up" state of the button does a mouseDown on the Button then slides off and does a mouseUp off stage. #### DataGrid DataGrid has code that resizes the editor if the stage size changes and causes a re-layout of the DataGrid, and to dismiss the editor when the user does a mouseDown outside of the DataGrid. There is also code that dismisses the editor if the application loses focus. #### DataGridItemRenderer, ListItemRenderer, TileListItemRenderer, TreeItemRenderer These itemRenderers currently use the stage to calculate the postion of a datatip. #### ListBase ListBase also has code that looks for mouseUp anywhere in the application or off the stage. #### ScrollBar/ScrollThumb The ScrollBar has code that looks for mouseUp if the user does a mouseDown on the ScrollBar's track, then slides off and does a mouseUp anywhere, and for when the ScrollThumb is being dragged and released off stage. #### SliderThumb SliderThumb has code for when the Slider thumb is being dragged and released off stage #### Container Containers have code that checks the stage when container was enabled after being disabled. #### UIComponent UIComponents access the stage in order to handle callLaters, when certain effects finish, when setting focus. #### UITextField UITextFields check the stage when asked for their measuredWidth or measuredHeight #### BrowserManager We could modify BrowserManager to delegate to the main application's BrowserManager when in a different ApplicationDomain, but I think the right thing to do is to simply not do anything (or throw errors) if sub-applications try to access the BrowserManager. The main application should have final say over what goes in the URL, and should be working off of a central data model in the main application. Which sub-application is loaded should be part of that data model and reflected in the UI. BrowserManager doesn't really have any automatic behavior today anyway. Folks have to write their own model-to-url conversion and vice versa so good applications will probably already have built in some sort of custom negotiation between the main application and sub-applications as even in the child ApplicationDomain scenario, you probably don't want your sub-applications to directly change the URL. Thus, the BrowserManager will simply shut down if it is not in the main ApplicationDomain, so it will be shut down if it is in a different SecurityDomain as well. #### CursorManager The CursorManager adds event listeners to the stage to track mouse movement when there is a custom cursor. If stage access in disallowed because the CursorManager is in a different SecurityDomain, the custom cursor will only appear over the area of the screen allocated to the CursorManager's application. Code will be added to detect that the mouse moved out of or back into that area of the screen and hide or restore the cursor appropriately. Whatever cursor is being shown by the CursorManager in the other SecurityDomain is restored when the mouse moves into the area of screen controlled by that SecurityDomain. All properties and methods on ICursorManager are only valid for that SecurityDomain and cannot affect or read back from the another SecurityDomain's CursorManager. If the CursorManager is in the same SecurityDomain as the main application, but in a different ApplicationDomain, the CursorManager will delegate requests to show a custom cursor to the main application's CursorManager. When in the same SecurityDomain, all properties and methods in ICursorManager are handled via delegation to the main application's CursorManager. The CursorManager must also be modified to handle custom cursors that are not UIComponents, as cursors passed from other ApplicationDomains cannot be typed as UIComponent. #### DragManager When the DragManager is in the same SecurityDomain as the main application, but in a different ApplicationDomain, the DragManager will generate the DragProxy in the sub-application's ApplicationDomain then pass that DragProxy to the main application's DragManager. The DragManager will have to be modified to cope with a DragProxy that is not strongly typed. All properties and mehtods in IDragManager are handled via delegation to the main application's DragManager. Applications sharing dynamic object data will be all set as Object's are in the player's ApplicationDomain and therefore shared, but if any custom classes are in the drop data, they cannot be shared as strongly-typed objects and it will be up to the application developer to override the drop events and marshall the data themselves. When the DragManager is in a different SecurityDomain from the main application, the user will not be able to drag data between the SecurityDomains. The DragProxy will stick at the edge of the application's area of the screen and the mouse cursor will change back to whatever mouse cursor is correct for the new SecurityDomain it is over. That's because the cursor is handled by CursorManager. There will be events shared between SecurityDomains so that if the user mouses up outside of the DragManager's SecurityDomain it will know that and cancel the drop. #### FocusManager The FocusManager is one of the few managers that will support interoperability even across SecurityDomains. That's because it is important for accessibility reasons, and because it is practical to make it work within our schedule and without violating security. Thus, FocusManager only needs two modes of operation instead of the three in most other managers. Most other managers will have one mode of behavior if they are in the main ApplicationDomain, a different mode of behavior if they are in the same SecurityDomain but different ApplicationDomain, and a third mode if they are in a different SecurityDomain. The FocusManager will either be in the main ApplicationDomain, or assume it is in a separate SecurityDomain. When in the main ApplicationDomain, the FocusManager will watch any SWFLoader in its IFocusManagerContainer. When a SWFLoader loads an application into another ApplicationDomain or SecurityDomain, that SWFLoader will be added to the list of focusableCandidates so it knows where the children of the SWFLoader belong in the tab-order. When it is time to transfer focus to children in that SWFLoader, a message will be sent to the FocusManager in the loaded application to take over focus. When that FocusManager has completed tabbing to its children it sends a message back to the main FocusManager. Other messages exist for when the user clicks on focusable controls owned by the various FocusManagers so the other FocusManagers can know that they should allow focus to move out of their set of controls. When focus is not in one of the controls owned by a FocusManager, calls to getFocus() on that FocusManager return null. Calls to UIComponent.getFocus() will also return null (should it throw an error?). Addtionally, the method getNextFocusManagerComponent will be deprecated in 3.2 and replaced by moveFocus() so that you can programmatically transfer focus to another FocusManager if needed. #### HistoryManager HistoryManager will not support being in different ApplicationDomains or SecurityDomains than the main application. #### LayoutManager The first modification to the LayoutManager is to allow it to get callbacks from the player when it is time to validate and layout the widgets in the application, and when the LayoutManager is in a separate SecurityDomain from the main application. The second modification to the LayoutManager will be the last thing on the schedule (and may get cut if we run short on time). In most cases it shouldn't matter that the LayoutManager in other applications are running independently. The only case we can think of right now is if the main application needs to know the measured width or height of the sub-application. Only then will we need to coordinate such that the sub-applications LayoutManager runs first. The expectation is that most main applications will probably dictate the area of the screen available to the child application, because the main application is usually fully laid out by the time the sub-application loads and the main application wants that sub-application to cover a specifc area of the screen. #### PopUpManager, Alert, Other PopUp-related Controls The PopUpManager modifications are pretty much like CursorManager. If in the same SecurityDomain but different ApplicationDomain, the popup is created in the ApplicationDomain and passed to the main application's PopUpManager which has to be modified to handle popups that cannot be strongly-typed as IUIComponent. When in different SecurityDomains, popups are parented by the SystemManager for that ApplicationDomain which means that centering will center in the area of the screen occopied by the sub-application and not the entire application, and that popups can be clipped by scrollbars and masks on the sub-application. Alert will be modified to pass the Alert parameters across a SecurityDomain boundary to the main application so that Alerts can get displayed there. Alert events will be returned to the calling application by supplying a proxy listener. However, customization of the Alerts styles will not work since we don't want to take the time to marshal style declarations across SecurityDomains. We will add an additional parameter to Alert.show to indicate that the Alert should just happen in the sub-application and not be passed to the main Application. Various popup-related controls like ColorPicker, ComboBox, DateField, PopUpButton, PopUpMenuButton, Menu will need modification to display the popup in a different direction if the popup is in a different SecurityDomain than the main application and the popups normal position would cause it to be clipped. Modal windows are extremely tricky as a sub-application cannot mask off the main application when in separate SecurityDomains. A protocol will be established to have the main application mask off its areas, but there might be mismatches between gradients and effects at the boundaries of the sub-applications area of the screen. #### SystemManager SystemManagers handle multiple "top-level" windows within an application. A floating dialog, or MS Windows-like MDI applications with several panels that overlap are supported by SystemManager today. When a different top-level window is activated, the SystemManager deactivates the FocusManager in the formerly active top-level window and activates the FocusManager in the other and changes the z-order of the windows. When in the same SecurityDomain but different ApplicationDomains, the SystemManager will delegate to the main application's SystemManager. The main application's systemManager will be modified to handle top-level windows that are not IUIComponents. When in different SecurityDomains, a protocol between SystemManagers will be established to allow for proper activation and deactivation of FocusManagers in the various SecurityDomains. Since floating windows in a sub-application in a different SecurityDomain is restricted to that sub-application's area of the screen, z-order issues don't really come into play, but the order of activation and deactivation should be kept intact. When you popup a non-modal dialog in the main application, then one in the sub-application, then remove the popup in the sub-application, the popup in the main application should get activated. #### ToolTipManager The ToolTipManager is pretty much like CursorManager. When in the same SecurityDomain, but different ApplicationDomains, the tooltip will be created in the sub-application's ApplicationDomain and passed to the main application's ToolTipManager. The ToolTipManager will be modified to handle ToolTips that are not IUIComponents. When in a different SecurityDomain, the tooltip is parented by the sub-application's SystemManager and can therefore be clipped and masked by the main application. The ToolTipManager's placement logic will be modified to re-style and re-position the tip so it fits within the sub-application's area of the screen and not the entire stage. #### Services Some applications centralize their communication to services. It even appears to be required for AMF as they classes reconstructed by AMF requests must be in the main ApplicationDomain regardless of which code called the service. This needs to be proven out for separate ApplicationDomain and separate SecurityDomain topologies. Other applications using WebServices might even have FlexBuilder break down the WSDL into classes shared throughout the application. When the sub-application moves from being in a child ApplicationDomain to a separate ApplicationDomain, it isn't clear that AMF calls will work. If the sub-applications were coded to directly access the HTTPService or WebService in the main application, that will no longer work. It isn't clear what we'll do here. It might just come down to recommended development practices and examples of how to marshal service requests and results across ApplicationDomain boundaries. We probably won't do any work to support access across SecurityDomains since if you don't trust the application you shouldn't let it access your services. **Note: see implementation to understand how we actually went about solving this, at least partially.** #### Models and other Singletons Models that are implemented as Singletons, and other singletons shared by an application and its sub-applications will not work once the sub-applications are in separate ApplicationDomains. Just like Services, you should not be sharing data models and other singletons with untrusted applications. We will probably just supply examples of how to implement sharing of models and other singletons ### Impact on Application Development As you can see, the rules of ApplicationDomains have impact on not just the Flex Framework, but on the developer's code as well. The developer will have to plan upfront for eventual mixing of versions. If they start out using untrusted applications in different SecurityDomains, they'll see right away that the cannot drag between applications and tha cursors don't move between applications and plan accordingly before they ship. But if the developer is using trusted applications in the same SecurityDomain, they can end up with failures as soon as they load a sub-application into a different ApplicationDomain in the same SecurityDomain as the following will not work correctly: * BrowserManager calls from the sub-application will not work * Dragging custom class data between applications will not work. * HistoryManager will not work. * Modal windows may have some visual artifacts. * Shared web services will not work. Thus, it will be important for these limitations to be communicated to developers planning to mix versions and demonstrate best practices for them to use in their applications. The developer will have to: * Implement usage of BrowserManager (so that HistoryManager isn't turned on by accident) and implement a scheme to handle URL updates from the sub-applications * Implement marshalling for any drag-drop behavior between applications. * Turning off any visual aspect to modal windows. * Implement marshalling for web services * Put all data classes used by AMF in the main application. ## Implementation Details ### Inter-application Communication All communication between ApplicationDomains or SecurityDomains use the LoaderInfo.sharedEvents dispatcher and custom events. It is important to note that even the custom event classes cannot be strongly-typed by the receiver so receiving code relies on unique event names to distinguish the differences between events. The sharedEvents dispatcher is not only used by the Flex Framework code implementing the Marshall Plan, but probably also by the application developers code if they have to marshall data between ApplicationDomains or SecurityDomains, and thus we need to guarantee uniqueness of all event names involved in the Marshall Plan. We will probably prefix our event names since these events will not be used in MXML. ![](clientdiagramjpeg.jpg) The diagram above attempts to illustrate how the sharedEvents dispatcher works and where it lives between two Flex applications. The main application has a SWFLoader that wraps a flash.display.Loader that has a contentLoaderInfo property that has reference to the sharedEvents dispatcher. The sub-application has a loaderInfo property that has a reference to the same sharedEvents dispatcher. When the sub-application's PopUpManager sends an event through the sharedEvents dispatcher, it might be a custom event type like SandboxBridgeEvent. However, because the event is crossing an ApplicationDomain or SecurityDomain boundary, it is received in the main application as a plain Object, although it retains its set of properties. Any objects referenced by that object are also of type Object unless the sub-application is in the same SecurityDomain and those objects are in the flash.**.** packages. Another important concept to realize is that because the sub-application is listening to the same sharedEvents dispatcher for events from the main application, the sub-application could have its listeners get called when it dispatches the event if the main application uses the same event name to talk back to the sub-application.. Thus event objects will have names that are only used for communication in one direction or references to the dispatching object so the listeners can determine if they are just hearing an echo. We can't use event.target because that will be the same whether the main application or sub-application dispatched the event since event.target points to the sharedEvents dispatcher no matter who dispatched the event. ### Communication Protocol There are two categories of communication between applications: requests and notifications. In the event model, there aren't supposed to be return values from calls to dispatchEvent other than a true/false as to whether the event as cancelled. The event objects are not supposed to be modifed by a listener and then examined by the dispatcher after dispatchEvent returns. The protocol is therefore designed to try to eliminate the need for responses from the listeners. #### Requests A request is something like "please parent this popup" or "please let me know about mouse messages from other security domains". #### Notifications A notification is something like "the mouse was clicked outside your screen area" or, "A popup in my SecurityDomain got activated". Notifications generally help the application find out about things it might need to know about that are happening outside of its screen area, but should not expose so much information that it allows the untrusted application to get a sense of what is happening in the other applications. ### Security We have chosen not to use the parentSandboxBridge and childSandboxBridge when running on AIR. AIR supports sharedEvents so we will implement the Marshall Plan entirely using sharedEvents whether running on AIR or the web. Event objects passed between applications via sharedEvents will generally not contain references to other objects. Known exceptions are: * We will pass around references to various sharedEvents objects across SecurityDomains. These objects are used by other applications as the place to dispatch information about mouse messages in a foreign ApplicationDomain so the listener on the other side can know, for example, whether the mouse button was released. There are no references to other objects from a sharedEvents object so having a reference to the sharedEvents object from another SecurityDomain should not be a security violation. * If the application is in the same SecurityDomain but a different ApplicationDomain, it will pass references to DisplayObject in order to request that they get parented by the top-level application. Most managers need to know if they are operating in a trusted environment or not, because that will dictate whether references to objects in one application will be passed to the other application over sharedEvents. One of the key tasks is to figure out how to know we're trusted. We don't have an answer for this question yet. When the managers are operating in an untrusted environment, they will not respond to certain requests, such as a request to parent an DisplayObject, or return the dimensions of the Stage.

[[ include ref='flexsdk_rightnav' ]]

Recent changes to Marshall Plan

WikiPage Marshall Plan modified by SourceForge Editorial Staff

WikiPage Marshall Plan modified by SourceForge Editorial Staff