Puppeteer
Component-based Adaptation for Mobile Computing

Department of Computer Science
Rice University


Mobile and wireless environments are characterized by limited and unreliable resource availability.   In contrast, desktop applications, such as office productivity suites, typically expect that resources such as bandwidth and power are available in abundance.   To breach this gap, the applications need to be adapted to perform properly in these environments.   While several approaches to adaptation have been proposed, very few systems have been deployed widely mainly because these approaches require extensive modifications to an application's source code.

Puppeteer demonstrates new a approach to application adaptation called component-based adaptation.  The novel premise in component-based adaptation is that the applications provide mechanisms to enable adaptation by exposing run-time Application Programming Interfaces (API) to external programs.  The adaptation system adapts applications without changing their source code by instead calling their APIs.  For example, when browsing the Web over a bandwidth-limited link the adaptation system reduces the time to load a Web page by providing low-fidelity versions of its images.   Later, as the user reads the page, the adaptation system acquires higher-fidelity images and replaces the browser's original images, using the browser's APIs.  Applications thus become components that can be manipulated by the adaptation system.  Because no source code modifications are necessary, component-based adaptation overcomes the principal roadblock to deploying adaptation.

We have used Puppeteer to adapt widely deployed applications such as Internet Explorer, Microsoft PowerPoint, and Sun's OpenOffice.  Puppeteer adapts applications for reading, editing, and collaboration over bandwidth-limited devices and supports system-wide adaptation policies that adapt multiple applications in concert.  Puppeteer achieves significant latency, bandwidth, and energy reductions for various adaptations over bandwidth-limited links, and adds little overhead when no adaptation is done.  The programming effort to support new applications and new policies is modest, and code can be re-used to implement similar policies for different applications.

Project Members:

Contents:



System Overview

Puppeteer is a new system we have built to support a new form of adaptation we call component-based adaptation.   Puppeteer takes advantage of the modular component-based structure, consistent file formats, and exposed APIs of modern applications.   By remotely ``pulling strings'' on these applications, Puppeteer can add a wide variety of adaptation policies to pre-existing applications without modifying them in any way.

Figure 1:System architecture.

Figure 1 shows the four-tier Puppeteer system architecture.  It consists of the application(s) to be adapted, the Puppeteer client proxy, the Puppeteer server proxy, and the data server.  The application and data server are completely unmodified.   The Puppeteer client proxy and server proxy work together to perform the adaptation.

The Puppeteer client proxy is in charge of executing the policies that adapt the applications.   The Puppeteer server proxy is assumed to have strong connectivity to the data server.  In the most common scenario, it executes on the same machine as the data server.   The Puppeteer server proxy is responsible for parsing documents, exposing their structure, and transcoding components as requested by the client proxy.   Data servers can be arbitrary repositories of data such as Web servers, file servers or data bases.

Puppeteer Architecture

Puppeteer can adapt an application if it can uncover the component structure of its documents and if the application provides a run-time interface that enables Puppeteer to view and modify the data the application operates on.   We refer to the latter feature as Data Manipulation Interface ( DMI ).   Additionally, Puppeteer can benefit greatly from being able to track the user as she uses the application.

Figure 2: Puppeteer architecture.

The Puppeteer architecture consists of four types of modules: Kernel, Driver, Transcoder, and Policy (see Figure 2).   The Kernel is a component-independent module that implements the Puppeteer protocol.  It appears once in both the client and server Puppeteer proxies.

A driver supports adaptation for a particular component type.   A driver for a particular component type may call on a driver for another component type, if a component of the latter type is included in a component of the former type.   At the top of this driver hierarchy sits the driver for a particular application (which itself is a component type).

Puppeteer supports three types of drivers: import, export, and tracking drivers.  The import drivers parse the documents, extracting their component structure and converting them from their application specific file formats to a Puppeteer Independent Format (PIF), consisting of a skeleton and a set of related data items.   Export drivers un-parse the PIF and update the application using the DMI interfaces exposed by the application.  A minimal export driver, has to support inserting new components into a running application.  Tracking drivers are necessary for many complex policies.  A tracking driver tracks which components are being viewed by the user and intercepts load and save requests.  Tracking drivers can be implemented using polling or event registration mechanisms.

Drivers may execute both in the client and the server Puppeteer, as may Transcoders which implement specific transformations on component types.

Policies specify particular adaptation strategies and execute in the client Puppeteer proxy. These policies traverse the skeleton, choosing what components to fetch and with what fidelity.

The Adaptation Process

The adaptation process in Puppeteer is divided roughly into three stages: parsing the document to uncover the structure of the data, fetching selected components at specific fidelity levels, and updating the application with the newly fetched data.

When the user opens a (static) document, the Kernel on the Puppeteer server proxy instantiates an import driver for the appropriate document type.  The import driver parses the document, extracts its skeleton and data, and generates a PIF.  The Kernel then transfers the document's skeleton to the Puppeteer client proxy.  The policies running on the client proxy policy ask the Kernel to fetch an initial set of components from within the skeleton at a specified fidelity.

The policies then use the export driver to supply this set of components to the application as though it had the full document at its highest level of fidelity.   The application, believing that it has finished loading the document, returns control to the user.  Meanwhile, Puppeteer knows that only a fraction of the document has been loaded and will use the techniques described above to fetch or upgrade the fidelity of the remaining components.



Publications



? since October, 2000.