The focus of the Ficus, Rumor, and Seer projects has been to ensure that data is locally available for use by a mobile user. Unfortunately, there will always be cases in which the user requests data that is not stored locally. Variations in network connectivity, frequently experienced by mobile users, compounds this problem. The user's ability to retrieve data from the network may be limited by many factors:
| Size | Is there space to store the data? |
| Speed | How long will the user wait for transmission? |
| Cost | How much will the user pay for transmission? |
| Level of Security | Can the data be retrieved securely? |
| Power | How much power will be consumed in transmission? |
| Urgency | Is there a time limit? |
| Latency | Must requests be made in advance of need? |
Each of these factors might be constantly changing during a mobile session. Our goal is to build a system that can automatically adapt to changing networking conditions and provide the best possible service in spite of the limitations.
Coping with networking limitations involves changing either the timing or the data in a transaction. Data might be compressed, encoded, encrypted, or thinned. Transactions may involve pre-fetching and/or caching. Determining which method(s) will be most effective depends on the type of data and the limiting factors of network connectivity.
Our solution will include modules which will perform specific adaptations. Each adaptation is suited to particular data types and network limitations. An appropriate set of adaptations is chosen automatically by the system. New modules can be constructed and "plugged in" to adapt to new data types and limitations.
Since some modules may lower the fidelity of the data, it may be desirable to retrieve incrementally improved versions of data. The initial request would be serviced by the initial version of the data. Subsequent requests might be serviced by improved versions. Eventually, a complete version of the data might be delivered to an existing replication system for local service of future requests.
Applications making use of the system may be either aware or unaware of the adaptation system. An API will allow aware applications to tune the adaptations and obtain feedback from the system. Unaware applications will receive data processed by the system via the standard interfaces. Thus, existing applications will make use of the system without modifications.
We hope that through automatic adaptation, such a system will provide the greatest use of available resources.