The need for application adaptation in mobile and wireless environments is well established [7,12,13,20,27,32,33]. On one hand, mobile environments are characterized by low and unstable resource availability. On the other hand, mobile users often want to access remote data using the same applications they use on their desktop machines. Unfortunately, many of these desktop applications require a rich and stable resource environment. They perform poorly when used on mobile clients, and require adaptation to provide acceptable levels of service. Many approaches to adaptation have been proposed before, and many taxonomies of adaptation are possible. We focus here on the types of adaptation policies as well as on where the adaptation is implemented.
Adaptation policies can be grouped into two types: data and control. Data adaptations transform the application's data. For instance, they transform the images in a document into a lower resolution format. Control adaptations modify the application's control flow (i.e., its behavior). For instance, a control adaptation could cause an application that otherwise returns control to the user only after an entire document is loaded to return control as soon as the first page is loaded.
Based on where the adaptation is implemented, we recognize a spectrum of possibilities with two extremes: system-based [21,26] and application-based adaptation [14,15,18,34]. With system-based adaptation, the system performs all adaptation by interposing itself between the application and the data; no changes are made to the application. With application-based adaptation, only the application is changed; the system is unaware of any adaptation. Application-based adaptation allows both data and control adaptation, while system-based adaptation is limited to data adaptation. System-based adaptation does not require modification of the applications, and provides centralized control, allowing the system to adapt several applications according to a system-wide policy.
In this paper, we present a novel approach to adaptation we call component-based adaptation. It enables application-specific control and data adaptation policies without requiring modifications to the application. It does so by using the exposed APIs of component-based applications and the structured nature of the documents they manipulate to implement application-specific control adaptation policies. Component-based adaptation attempts to bring together the benefits of system-based and application-based adaptation, namely to implement application-specific policies without modifying the applications. Since adaptation is done in the system, component-based adaptation retains the advantage of providing a centralized locus of control for adaptation of multiple applications.
Component-based adaptation enables policies that adapt by repeated use of subsetting and versioning. A subsetting policy creates a new virtual document consisting of a subset of the components of the original document (e.g., the first slide in a presentation). A versioning policy chooses among the multiple instantiations of a component (e.g., instances of an image with different resolution). The adaptation policies use the application's exposed API to extend the subset or to replace the version of a component (e.g., load additional slides in a presentation or replace an image with one of higher fidelity). This iterative improvement is one of the key advantages of component-based adaptation over system-based adaptation.
Another approach that tries to strike a middle ground between system- and application-based adaptation is application-aware adaptation [6,28]. Here, the system provides some common adaptation facilities, and serves as a centralized locus of control for the adaptation of all applications. The applications are modified to implement control adaptations and to perform calls to an adaptation API provided by the system. Component-based adaptation has similarities to application-aware adaptation in that both approaches delegate common adaptation tasks to the system. The approaches differ, however, in how control adaptation policies are implemented. In component-based adaptation, it is the applications that expose the interfaces, with the system invoking those interfaces to perform adaptation. The precise opposite occurs in application-aware adaptation where the applications are modified to call on the system's adaptation API. Component-based adaptation enables third parties to add new adaptation policies after the application has been released, while application-aware adaptation requires the application designer to foresee all necessary adaptations at the time the application is written.
Component-based adaptation is by nature restricted to component-based applications with exported APIs. While certainly a limitation, we observe that many desirable candidate applications for adaptation are already component-based, including the Microsoft Office Suite, Internet Explorer, Netscape Navigator, the KDE Office Suite, and Star Office. Recognizing the advantages of component-oriented software construction - independent of adaptation - we foresee an increasing number of applications being developed as components with exported APIs. Although traditionally associated with the Windows platform and with COM/DCOM technology, component-based technologies are becoming more common in the UNIX world as well, where the push for component-based technologies is led by the GNOME [1] and KDE [3] projects. A good example is KOffice [4], an open source productivity suite with powerful scripting capabilities. More recently, StarOffice [5] released version 5.2 of its popular cross-platform productivity suite, which implements a sophisticated object model that allows scripting by third party applications through a CORBA-based interface.
The more fundamental question about component-based adaptation is to what extent it can support the adaptation mechanisms that a customized application-based approach can achieve and with what performance. Furthermore, we wish to understand the scalability of component-based adaptation. Clearly, the system needs ``drivers'' for each application it wishes to support. For the concept to be scalable in terms of the number of applications it supports, the effort involved in writing an additional driver must be made small.
To address these questions, we have built a system we call Puppeteer. This paper describes the design of the Puppeteer system, its implementation on Windows NT, and our experience using this implementation to adapt two applications for low bandwidths, Microsoft PowerPoint (a presentation graphics system, hereafter ``PowerPoint'') and Internet Explorer 5 (a Web browser, hereafter ``IE''). We demonstrate that Puppeteer can easily and efficiently support a number of desirable policies.
The rest of this paper is organized as follows. Section 2 presents the design of the Puppeteer system. Section 3 introduces the prototype implementation and the applications we use to evaluate it. Section 4 describes the experimental platform. Section 5 describes the documents we use in our experiments. Section 6 presents our experimental results. Section 7 discusses related work. Finally, Section 8 presents our conclusions.