- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 1 Jul 2009 09:11:53 -0700
- To: Chris Anderson <jchris@apache.org>
- Cc: public-webapps WG <public-webapps@w3.org>
- Message-ID: <5dd9e5c50907010911g381fc000oc981552cd30e70a0@mail.gmail.com>
On Wed, Jul 1, 2009 at 2:55 AM, Chris Anderson <jchris@apache.org> wrote: > Hello, > > Long time fan, first time writer. ;) > > I've been following the Web Storage proposals with interest, and was > just independently drafting a mail suggesting the a B-Tree API would > be much simpler to standardize, and would be an adequate foundation > for building most anything more specific. > > I'd like to express my support for a BDB style API. Firstly because it > would be much less prone to vendor differences, and secondly because I > can see how to implement a performant CouchDB on top of it. It could > be a bit harder to build a SQL-like interface on raw B-Trees, but > completely possible if someone is determined. > > I don't think we need to worry about specific vendor implementations, > just a unified API with very small surface area. To build CouchDB all > we'd need is B-Trees that support in-order and reverse-order > traversal, and optionally user-defined collation functions. > > Here's a first cut at imagining the API: > > === JS pseudocode === > > var btree = new WebStore("dbname", <optional collation function > definition>); > > btree["mydocid"] = {"some":"json"}; > > btree.forEach(function(key, value) { > // in order traversal > }) > > btree.forEach(function(key, value) { > // reverse order traversal > }, false) > > btree.forEach("startkey", function(key, value) { > // in order traversal, starting from "startkey" > // we could use throw() to stop traversal > }) > > btree.forEach("endkey", function(key, value) { > // reverse order traversal, starting from "endkey" > // use throw() to stop traversal > }, false) > > // delete a btree > WebStore.drop("dbname"); > > === > > Thoughts? The biggest thing I see missing is transactions. Also, I don't know why web databases decided not to allow deletion or enumeration of the database names, but I assume it was difficult or impossible to do so in a non-racy way. It's definitely worth looking into this before supporting some sort of drop. And if we did support it, it seems as though the name could be more clear. The rest seems reasonable. I'm still concerned that this is not differentiated enough with LocalStorage. The differences are: duplicate keys, values besides strings, multiple stores, more powerful enumeration, and transactions (maybe others I'm missing?). Yet, from a novice developers perspective, I don't think it'd be clear at all what the differences are. I'm not sure how to reconcile this since LocalStorage is one of the standards supported by pretty much everyone--including IE. J
Received on Wednesday, 1 July 2009 16:12:33 UTC