If you are building an offline capable application, then I would posit that at some level in your client architecture you are going to need a Proxy. On one side of the Proxy will sit your presentation logic, on the other side will sit your business logic. When operating in online mode this Proxy will pass requests on to the remote server, when operating in offline mode the Proxy will redirect requests to some local implementation of business logic that provides a facsimile of the remote server’s behaviour.
For browser based applications, I feel a desirable place to position such a Proxy is at the browser’s HTTP interface. Implementing a Proxy at this level means that all means of initiating HTTP requests from within a browser can be proxied. Indeed Google Gears takes exactly this approach, providing a
ResourceStore into which resources can be cached, Gears then intercepts all HTTP requests made by the browser and if it detects a matching HTTP
GET request for a stored resource, serves the cached version of the resource from the
ResourceStore. This provides a means for an application to provide the static data it needs to ‘read’ when offline, but what about data the application needs to ‘write’ when offline? What about ‘read’ data that is constructed on the fly, for example the results of a query?
ResourceStore, BITSY also specifies a
DataCache to provide offline resource storage.