Requirements for and components needed in real Web Storage

Several times I have prodded people to provide requirements to WebStorage. Here's what I have gathered from use cases and scenarios people have suggested for WebStorage's scope:

Here are three sets of requirements as I see them:

Structured key-value pair storage and cursors

1. Store, remove, and retrieve individual data items
   1. items identified by a string key
   2. item values can be either null, object, or string
2. Allow duplicate values for the same key
3. Allow organization of items in to more than one database per application
4. Sequentially walk items in a cursor starting at a point identified by a key value
   1. items should be presented in an increasing key value as determined by JavaScript's String comparison operator '=='
   2. once the highest key value is reached, no more items are provided
   3. if the matching key value is empty, the first key in the database is the starting point
   4. can walk through items in reverse order
   5. items obtained in the cursor are deletable - IOW, cursor is modifiable
5. Provide a sequence object in each database to generate a monotonically increasing sequence of numbers
6. A database belongs to a single storage unit.
7. Applications are able to open or create a storage unit.
8. Allow storage of multiple items to be committed as part of an atomic transaction
9. Offer READ_COMMITTED and READ_UNCOMMITTED cursors
10. Transaction scope is limited to operations on databases within the same storage unit.
11. All APIs are synchronous

HTTP Cache programming:

1. capture a resource that is used for satisfying GET & HEAD requests
   
   1. given just its URL, fetch and durably store its representation
      
   2. as a locally produced representation
   3. over write an existing representation
2. retrieve or remove a resource's representation or check for its presence

HTTP interception:

1. Store the methods on resources that are locally intercepted
2. Choose among the following for a locally intercepted method
3. Pass the headers and body of the request, without jeopardizing security, to the programmed interceptor
4. Make the request to the server, relay the request and the response to the programmed interceptor, and return the response to the application

A JS library for synchronized Web storage would use all three components to process network requests locally using HTTP interception, respond to queries locally using the b-tree storage and the HTTP cache as well as store pending requests for forwarding to the server when it is reachable.

A pictorial representation of the layers involved in an implementation of CouchDB to run in a browser captures the contrast between the existing and the proposed breakdown of Web Storage.

The browser is then required to do the switching between off-line and on-line and between relay and intercept as I explain in the post on BITSY 0.5.

As I see it, these requirements subsume the requirements known to date for Ian Hickson's Web Storage draft. Were it not for the widespread use of LocalStorage, we could do away with it completely because the b-tree store is a more robust way of dealing with key-value pairs. However, there is no reason and, hopefully, little chance of the SQL portion making its way to the W3C hall of fame, I mean Rec.