[ Software Research Group ]

Application Framework

Today's window systems, like Windows 3.0 and the X Window System, assume a fixed base computer on which information will be displayed. Although they can handle multiple screens, they do not do well with applications that start out in one place (screen, computer, or room) and then move to another. For higher performance they assume a fixed screen and input mode and use the local computer to store information about the application--if any of these change, the window system stops working for that application. Even window systems like X that were designed for use over networks have this problem--X still assumes that an application once started stays put. The solutions to this problem are in their infancy. Systems for shared windows, such as those from Brown University and Hewlett-Packard Corporation, help with windows, but have problems of performance, and do not work for all applications. There are no systems that do well with the diversity of inputs to be found in an embodied virtuality. A more general solution will require changing the kinds of protocols by which application programs and windows interact. - Mark Weiser

The Gaia Application Framework adapts the traditional Model-View-Controller (MVC) application model to the computing model defined by Active Spaces.  Applications are constructed in a generic way, using abstract descriptions of the required components that make up the application.  The abstract application description can then be used to construct the application based on the hardware resources that are available in a particular space.  This is in contract to typical applications that assume a display, mouse, and keyboard.

The application framework is based on a model called Model-Presentation-Controller-Coordinator (MPCC) and is conceptually similar to MVC, although it renames the View component to Presentation, and adds an additional component called Coordinator. The model implements the application logic, the presentation exports the data of the model, the controller introduces changes in the model (the model automatically notifies all presentations), and the coordinator is responsible for managing the composition of the previous three components. We use the term Presentation instead of View to denote that the model's data cannot only be externalized as a viewable element, but also as an element that can be perceived by any human sense. The Coordinator exports functionality to modify the application structure, as well as functionality to monitor the status of the different components and react to changes according to user and system defined policies. The coordinator is recursively defined as an MPC application, whose model is the configuration of the assigned application (MPC base level). Any entity contained in the space can interact with the coordinator to alter the structure of the application.