[etech06] Disconnection Tolerant Ajax

the problem -

Web 2.0 mantra:
- Apps run on server
- client is just a communication and display device

Ajax assumes constant connectivity

Connectivity may be flaky or slow or unavailable.

Leads to a style of work that can be termed Frequently Connected Computing
- a presumption of network availability
- bot both planned and unplanned outages occur
- you want to continue some work during disconnections

drive-through-internet.org

To do this, apps have to be disconenction tolerant and delay tolerant.

Hw to do this?
- 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

Leads to single-page apps, but with Ajax backend.
- Download "working set" with page
- this can 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)

In error checking there are bugs in browsers you have to work around - error-protecting the error detection. Keep in mind that responses may not come back in the order they were sent.

Don't lose user input - can be kept as page state (e.g. in text areas); JavaScript state (in variables) - both of those methods have problems if the browser or system closes. You can store it in cookies or in some storage made available by a plugin (like flash SharedObject).

PANIC - Persistency for Ajax in Networks with Intermittent Connectivity.

You need to plan for data changing on the server while you're offline. Use conflict resolution strategies, like server-based generation numbers an dlocal generation numbers. THe cookie size limitation is a problem.

Proof of concept implemented on Prototype library, server parts based on Rails before_filter.

Technorati Tags: etech, etech06