We use PowerPoint and IE as the initial applications for our prototype. Besides being widely popular, these two applications comply with the requirements for DMI, parsable file formats, and tracking mechanism from Section 2.1. Furthermore, PowerPoint and IE have radically different DMIs. By supporting both, we are more likely to accurately design the interfaces between the Puppeteer Kernel and the component-specific aspects of the system. Next, we discuss the design of the drivers, transcoders, and policies that we have implemented to adapt these two applications. Table 1 shows the code line counts for the various modules.
Table 1: Code line counts for Kernel, PowerPoint (PPT) and IE modules .
PowerPoint 2000 supports two native file formats: the traditional binary format based on OLE archives [22,23], and a new XML-based format [24]. We choose to base the PowerPoint import drivers on the XML representation because it contains roughly the same information as the binary format, and the human readable nature of XML makes it easier to parse and manipulate the document. We have implemented import drivers for the following component types: PowerPoint, Slide, Images, Sound, Embedded Objects.
For IE, while HTML is straightforward to parse, the introduction of JavaScript in DHTML [16] has allowed for documents whose structure can change dynamically. For DHTML, the import driver intercepts URL requests, allowing it to dynamically add new images and components to a Web page's skeleton (see Section 2.2.2). We have implemented import drivers for the following component types: IE, Images.
PowerPoint and IE DMIs are based on the Component Object Model (COM) [8] and the Object Linking and Embedding (OLE) [9] standards. The interfaces they provide are reasonably well documented [25,31] and have traditionally been used to extend the functionality of third-party applications.
The PowerPoint and IE DMIs provide excellent access to compose and modify internal data structures. To support the policies we have implemented for this paper, the PowerPoint export drivers includes support for opening and closing presentations, and for inserting slides, images and embedded objects. The IE export driver includes support for navigating to a URL and for reloading individual components of a page.
To update an object in IE, the IE export driver instructs IE to reload only the URL associated with the object. PowerPoint supports a cut-and-paste interface to update a presentation. To paste new components into an active PowerPoint presentation, active, the PowerPoint export driver creates a new PowerPoint presentation, helper, that consists only of the new components. The update process has two stages. In Stage 1, the driver instructs PowerPoint to load helper. In Stage 2, for every component in helper, the driver copies it to the clipboard, pastes it into active, and deletes any earlier version of the same component from active.
PowerPoint's event notification mechanism is primitive and encompasses just a handful of large-granularity events like opening or closing of documents, making it inadequate for tracking the behavior of the user. The PowerPoint tracking driver relies, instead, on polling the DMI to determine the slide currently being displayed.
The IE tracking driver uses IE's rich event mechanism that allows third-party applications to register call-back functions for a wide range of events. The driver uses this interface to detect when the user types a URL, presses the back or forward buttons, clicks on a link, or moves the mouse over an image. The former events are used to instruct the Kernel to open a new HTML document, while the latter is used by policies to drive image fetching and fidelity refinement (e.g., refine the image currently pointed by the mouse).
The above policies use the following transcoders:
This section presents some sample adaptation policies that illustrate the power of component-based adaptation. These policies would be difficult to implement in system-based adaptation, because they affect not only the data used by the application, but also its control flow. Such adaptation policies have, to the best of our knowledge, only been implemented by modifying the application. In Puppeteer, however, they are implemented by using the external APIs. As will be demonstrated in Section 6 these policies also result in significant benefit under limited bandwidth conditions.
To adapt a new application with Puppeteer we need to implement drivers, policies, and transcoders for each new component type that is not currently supported by Puppeteer. For example, to enable MS Word we need to add drivers for the Word component type, but we can reuse the drivers and transcoders for the image and embedded object component types that we have implemented for PowerPoint (see Table 1).
While the effort in adding new applications and new policies is limited by the modular design of Puppeteer, the lack of standard DMIs, event models, and file formats requires new drivers to be written. Designing such standard interfaces is part of our ongoing research.