[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