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
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.
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.