Link

Arthur M. Keller Stanford Univ., Stanford, CA
Owen Densmore Sun Microsystems
Wei Huang Sun Microsystems
Behfar Razavi Sun Microsystems

Mobile Networks and Applications archive
Volume 2 , Issue 4 (January 1998) table of contents
Special issue on personal communications services
Pages: 357 - 364
Year of Publication: 1997
ISSN:1383-469X

Abstract:
This paper describes an approach for handling intermittent connectivity between mobile clients and network-resident applications, which we call zippering. When the client connects with the application, communication between the client and the application is synchronous. When the client intermittently connects with the application, communication becomes asynchronous. The DIANA (Device-Independent, Asynchronous Network Access) approach allows the client to perform a variety of operations while disconnected. Finally, when the client reconnects with the application, the operations performed independently on the client are replayed to the application in the order they were originally done. Zippering allows the user at the client to fix errors detected during reconciliation and continues the transaction gracefully instead of aborting the whole transaction when errors are detected.


My Discussion:
Although pretty old, this paper caught my eye because it explicitely addresses the problem so many papers about mobile UIs ignore: walking into a connectivity dead spot. The paper describes the error-handling system called 'Zippering' for this disconnection problem built into DIANA, a method and implementation for information retrieval competing with HTML/HTTP and the agents based Telescript. (In fact, the paper is so old it discusses HTML/HTTP by the name of 'Mosaic', NCSAs name for its WWW browser.) Zippering works by having the application being accessed over the network also have a small surrogate available on the client. For example, a group calendaring application written with DIANA would also on the client have a calendaring surrogate that would approve all meetings requested. When the user, while using the remote application, gets disconnected, the surrogate takes over responding and approves every requests. When the mobile device then re-connects, the surrogate replays the information exchange between UI and surrogate to the remote application, and alerts the user when the remote application reacts differently (denies a meeting in this example) from the surrogate. The user gets a chance to change that request, after which the surrogate replays the other requests, and so on until the user is synchronised.
So is this paper now just a curiosity in a world where HTML/HTTP forms have become ubiquitous, and all infrastructure is based on web-servers, network caching, and Javascript? Not really, zippering is suddenly relevant again for mobile SOAP-based applications. When data access is being done by simple SOAP messages, writing a client that detects network breaks and then routes the SOAP messages to a surrogate becomes feasable, since the appliction developer is writing a custom SOAP client anyway. The SOAP surrogate on the client can the synchronise when the network is back, and catch up that way. Since SOAP has many interesting qualities for the mobile space, zippering may be necessary again just yet.