Towards Better Browser Storage

Chris Beard

10 responses

As Web applications become more powerful and useful, the need has arisen for them to be able to store structured information in the user’s browser. This is the problem that the W3C’s Web Storage specification has set out to solve.

At the moment, the specification aims to expose a particular implementation of SQL to web pages. Vladimir Vukićević has written about flaws in this approach. Among them are:

  • While a lot of server-side developers already know SQL, it’s actually quite low-level and not very easy to use. This goes against the grain of the Web as a platform, which is something that should be as easy to develop for as possible.
  • There’s no useful core SQL standard, and as a result the specification effectively says “do what SQLite does”. Because “what SQLite does” isn’t well-defined and can change in future versions of SQLite, it effectively means tying all browsers to a particular implementation, and any security vulnerabilities that the implementation may have.

It seems that a different approach is required and we’re highly interested in exploring alternative proposals to SQLite for Web Storage.

I’ve recently undertaken an experimental re-implementation of CouchDB in the browser to explore the possibilities of using a simpler standard that delegates many of its semantics to the JavaScript language and is also easily parallelizable to take advantage of multiple processor cores. For instance, putting posts into a blog database might look something like this:

blogDb.put(
  [{author: 'Myk', title: 'Burritos',
    content: 'Burritos are yum.'},
   {author: 'Thunder', title: 'Bacon',
    content: 'I like bacon.'},
   {author: 'Thunder', title: 'Beer',
    content: 'Beer is good too.'}],
  function onDone() { /* Do stuff... */ }
);

Take a look at the BrowserCouch Tutorial for more information on how this kind of Web Storage API would look and work—it also lets you play around with the MapReduce algorithm interactively, so you can really get a feel for it.

Please do let us know what you think, or if you have other ideas on how best to approach Web Storage.

— Atul Varma, on behalf of the Mozilla Labs team

10 responses

  1. Ashok wrote on :

    I’m curious to understand whether anyone has explored using Berkeley DB for this purpose. If you’re looking for a simple, get/put API for data management, I think Berkeley DB is ideal.

    If Berkeley DB was not adequate, I would love to understand what the limitations are.

  2. Matthew wrote on :

    With all due respect, I think you’re missing the point here.

    A relational database is most definitely higher-level (and more useful!) than a key-value store!

    To say that “SQL, is actually quite low-level” compared with something like CouchDB is just plain wrong.

    Now SQL may not be the ideal language, or the best-standardized, but that is a separate issue.

    Just giving up and resorting to a lower-level non-relational document-oriented database is not the answer to my mind, especially not on the client, where many of the perceived scalability downsides of using a relational database server-side do not apply.

  3. Kas Thomas wrote on :

    Not being a database professional, I hate SQL, but in this case I think the right thing to do is to use a well-accepted standard (SQL) for the use-case it was designed to handle. In other words, this is exactly the sort of thing SQL was designed to be used for. So use it. Then, if anybody wants to add some kind of JavaScript shim-layer over the top of it, so much the better. I, for one, would use the JS API if one were available.

  4. redapple wrote on :

    guys, rss refreshing still s*ks – +35 livemarks hangs browser at regular intervals, please do something with that.

  5. Tom Bonner wrote on :

    I agree totally with legoxx. Why muddy the waters with another flavor of storage? You suggest that SQL is “actually quite low-level and not very easy to use.”

    That may be true, but the fact remains that MySql is one of the most widely used DB applications for web use. Try to install WordPress without it. You will also find it used in dozens of other web applications. If you are going to manage online data structures, sooner or later you are going to have to work with SQL.

    Since knowledge of SQL will be extremely useful in any event, why not encourage users to learn it, rather than a much less widely-used solution? Not saying there isn’t room for CouchDB, as competition is always good for encouraging forward progress. In the end, however, the many flavors of SQL are too entrenched to be ignored.

  6. legoxx wrote on :

    tbh i belive that SQL is pretty wide used language for data manipulation. CouchDB with a javascript flawor seems much like reinventing a wheel to me. In my opinion we should stick with version of SQL. SQLight seems like a good choice for me, good for simple queries.. complex queries should run on the server anyway.

  7. Mark Finkle wrote on :

    I really like the way you are using localStorage/globalStorage as the persistence mechanism for the blob/document style data. The JSON access is pretty sweet too.

    I’m curious though, why a BrowserCouch-like API would need to be a standard? Shouldn’t we be able to use other JS wrappers, like Persevere’s JavaScriptDB, without needing one to be the standard?

    I guess I like localStorage/globalStorage being the standard and other wrappers being built on top of that. Since we have a blob/document type of storage standard, why wouldn’t we want a relation style storage standard too? Who knows what kind of cool JS wrappers will be built on that style of storage.

    I’d rather keep the standards at a lower level – more of a foundation – and allow JS libraries to blossom. Kind of like we see with Canvas.

  8. Simon wrote on :

    Looks pretty cool… the query syntax is a bit more complicated than SQL for simple examples, but looks like it’d be much better for doing anything complicated. And honestly, SQL is good for querying, but often poor for insert/update – a more OO syntax of “persist(object)” is usually much more convenient…

  9. Gil wrote on :

    You know, I like it, but I think it could become tedious having to retype the “columns”. I’d like the option to also do something like…

    blogDb.put(
    [author,title,content]
    [{‘Myk’, ‘Burritos’,’Burritos are yum.’},
    {‘Thunder’, ‘Bacon’,’I like bacon.’},
    {‘Thunder’, ‘Beer’,’Beer is good too.’}],
    function onDone() { /* Do stuff… */ }
    );

    Poor syntax, but you see what I mean.

  10. Jason Huggins wrote on :

    You rock, Atul. Great stuff!