Panic-mode: A Disconnection-tolerant AJAX Library

O’Reilly Emerging Technology 2006-03-09

Carsten Bormann

cabo@tzi.org

AJAX = Pizza

AJAX =
Bread (HTML) + Cheese (JavaScript) + Tomatoes (XMLHttpRequest)

More toppings:

• Real-Time AJAX (Alex Russell calls this “COMET”)
• Disconnection-Tolerant AJAX

Outline

The Web as the Platform

Web 2.0 mantra:

• Applications run on a server
• The client is just a communication and display device

AJAX assumes constant connectivity:

• inserting/updating page content based on server data
• sending user updates back to the server in the background

Realities of Mobile Work

For nomadic workers, connectivity may be flaky

• too many people using the WiFi at the conference
• moving vehicle (e.g., train)

or extremely slow

• GPRS networks

or unavailable

• too expensive (WiFi hotspots in Europe)
• outlawed (some hospitals, some airplanes)

Frequently Connected Computing

Intel: Occasionally Connected Computing

• but then, most of us take the Internet for granted

A better term would be: Frequently Connected Computing

• There is a presumption of network availability
• But both planned and unplanned outages do occur
• You do want to continue some work during disconnections

FCC and AJAX

For Frequently Connected Computing, applications need to be:

• disconnection tolerant
• delay tolerant

Making AJAX work with FCC:

• Put more of the interface on a single page
• Do serious error checking
• Don’t lose user input

Reduce number of pages

In disconnected mode, you don’t want to:

• change pages for routine operations
• rely on server data for routine operations
• fail mysteriously or verbosely on update errors

→ Single-page application, but with AJAX backend

• Download “working set” with page
  • this can actually be done with background AJAX
  • pace requests properly until page populated
• Structure UI, e.g. using tab-styled “navigation”
• Don’t forget bookmarkability (update location.hash)

Do serious error checking

How to handle network issues:

• use good error detection
  • don’t forget error-protecting the error detection
• correctly handle multiple requests that may be in flight
  • responses may not come in order!
• properly pace requests

What can be done in case of error:

• information request: display indication of (lack of) progress
• information update: keep changes around

Don’t lose user input

User input can be kept as:

• page state (e.g., in text areas)
• JavaScript state (in variables)
• Cookies
• Plugin state (e.g., Flash SharedObject)

→ Persistency

PANIC-mode

How not to lose input:

• keep changes around in case of error
• Persistent storage in Browser: Cookies

Approach: make the “backup” path the normal path:

• Information for all AJAX updates is stored in cookies
• Updates that get through are deleted by server (Set-Cookie:)

Disconnected Operation

Disconnection tolerance increases likelihood of data changing on the server

• Shared data (e.g., Wiki): High likelihood of concurrent changes
• Personal data: Concurrent changes from different devices!

PANIC-mode uses generation numbers to indicate conflicts

• Server-based generation number
• Local generation number to solve update completion race

Conflict: Actual merge needs to be done by application logic

Limitations

Browser and network/server implementations impose limits:

• Cookie size: should be < 4 KB
• Total number/size of cookies per site (e.g., Firefox: 200 KB)

Problem: Reaction to cookie overflow not really well-defined

• Need to double-check results of cookie updates!

Implications

Storing updates in Cookie = all changes are sent with each request

Good: No explicit action needed to send updates to server

• First server access sends all updates

Bad: Efficiency implications

• Overlapping requests cause additional bandwidth

Applications that fit PANIC-mode

Read/write applications:

• There is work that needs to be done
  • Creative work—slide show updates
  • Real-world work—looking at supermarket aisles
  • Non-work—gaming with score uploads
• The work benefits from the network
  • So you’re normally online when starting the work
• The network may not be available throughout the work
• The results are of moderate size

PANIC-mode: Status

Proof of Concept implemented based on Prototype library

• Server parts based on Rails before_filter

To do:

• Handle oversize updates
  • Capacity checks
  • Use something like dojo.storage as backup for larger updates
• More browser compatibility testing
• Packaging, release (watch https://prj.tzi.org)
  • BSD license