DWR

Some thoughts on what DWR + Gears should do:

Currently DWR is basically fire and forget. DWR+Gears should be more of a MQ style reliable message pipe. It would be implemented using a message store at both ends with a system of ACKs that allows retries safely.
The brings the following benefits to any DWR enabled website
- The ability to have the network go down, for a DWR application to make server requests while offline, and for these requests to be automatically and transparently replayed when the network returns
- A DWR application should be able to mark a request 'optional'. This would typically be useful for refresh operations. The 'save' is mandatory, but the refresh can be skipped if offline.
- DWR should do everything possible to help developers make full use of the LocalServer. There may be DWR resources that could usefully be cached, but more importantly DWR should not interfere, and should where possible integrate with Gears knowledge of the offline/online status of the application
- There needs to be some concept of a goneOffline hook and a goingOnline/goneOnline hook to allow an application to manually resync
- Currently DWR does not make any operation ordering guarantees, with message numbers and resend, these guarantees should be possible.
- Since DWR is scheduling resends, batching (grouping a number of requests into a single network request) should become an (optionally) automatic feature
- It should be a server switch to say "enable gears" i.e. gears integration requires thought from the developer

I'm thinking that it would make sense to have 3 client side message stores: Gears, DOL, and a simple hash if neither of the others is available.