IndexedDB: Thoughts on implementing IndexedDB

I've been meaning to implement IndexedDB in some fashion for a while.
Earlier this month, shortly after the call for implementations, I realized
I should be getting on that. I've been working on an in-memory ECMAScript
implementation with fast data structures and the like. I also intend to
experiment with new features like new types of indexes (hash tables that
can't be iterated, and index values calculated by expression/function,
which appears to have been discussed elsewhere).

I've had a few thoughts, mostly about language:

(1) Is there no way to specify an arbitrary nested path? I want to do
something like ['menus', x] where `x` is some token which may be anything,
like an empty string or a string with a period in it. This is especially
important if there are structures like {"http://example.com/URI": "value"}
in documents, which is especially common in JSON-LD. From what I can tell,
IndexedDB essentially makes it impossible to index JSON-LD documents.

It appears the current behavior instead allows you to index by multiple
keys, but it's not immediately obvious this is the rationale.

How *would* one include a property whose key includes a period? This seems
to be asking for security problems, if authors need to implement an
escaping scheme for their keys, either when constructing a key path or when
constructing objects. Database names can be anything, why not key names?


(2) There are still a few references to *Sync terms from the old
synchronous API. Specifically, IDBDatabaseSync and IDBCursorWithValueSync.


(3) I had trouble deciphering the exact behavior of multiple open
transactions on one another. I eventually realized the definition of
IDBTransactionMode describes the behavior.

Still, however, this document appears to talk in terms of what is "written
to the database". But this isn't well defined. If something is written to
the database, wouldn't it affect what is read in a readonly transaction?
(No.)

And the language seems inconsistent. The language for `abort` says that
changes to the database must be "rolled back" (as if every operation writes
to storage), but the language for `Steps for committing a transaction`
specifies it is at that time the data is written (as if all write
operations up to this point are kept in memory). There's not strictly a
contradiction here, but perhaps more neutral language could be used.


(4) The section "Steps for asynchronously executing a request" says "Set
/transaction/ to the `transaction` associated with `source`."

Perhaps it should instead say "Let /transaction/ be the `transaction` which
is associated with `source`"

Because /transaction/ is previously undefined.


(5) I found the language for iterating and creating a Cursor hard to
understand being nested in multiple layers of algorithms. Specifically,
where an IDBCursor instance was actually exposed to the user. But now it
makes sense, and I don't really see how it might be improved. An
(informative) example on iterating a cursor may be helpful.


(6) The document refers to the HTML5 Structured Clone Algorithm. It's a bit
concerning that it has to refer to ECMAScript algorithms defined in a
specification that defines a markup language. I don't think referring to a
markup language should be necessary (I don't intend on using my
implementation in an (X)HTML environment, just straight XML if anything at
all), though perhaps this is just a modularity problem with the HTML5 draft
(or rather, lack thereof).


Finally, is there a good test suite? I can't seem to find anything in the
way of regression tests. I'll perhaps publish my own, if not.


Austin Wright.