[IndexedDB] Lots of small nits and clarifying questions

I'm sorry that I let so much IndexedDB feedback get backlogged.  In the
future, I'll try to trickle things out slower.

*
*
*Indexes:*

1) Creation of indexes really needs to be made more clear.  For example,
does creation of the index block everything until it's complete or does the
database get created in the background?  What if I have 1gb of my mail
stored in IndexedDB and then a database migration adds an index?  Is my app
completely unusable during that time?  What if the browser is exited half
way through building (you can't just delete it)?  What happens if you query
the database while it's building in the background-building case (should it
emulate it via entity-store-scans)?  These are all very important questions
whose answers should be standardized.

2) Why are Indexes in some database-global namespace rather than some
entity-store-global namespace?  I know in SQL, most people use the table
name as a prefix for their index names to make sure they're unique.  Why
inherit such silliness into IndexedDB?  Why not connect every index to a
particular entity-store?

3) What happens when unique constraints are violated?

4) I don't remember anything explicitly stating that when a value changes
that an index has a keypath referring to, that index should be updated.

5) It definitely would be nice to be able to index more than just longs and
strings.

6) The specific ordering of elements should probably be specced including a
mix of types.


*Key ranges / cursors:*

1) Is an open or closed key range the default?

2) What happens when data mutates while you're iterating via a cursor?

3) In the spec, get and getObject seem to assume that only one element can
be returned...but that's only true if unique is true.  What do you do if
there are multiple?

4) Why can the cursor only travel in one direction?

5) What if you modify a value that then implicitly (via the key-path)
changes the index that your cursor is currently iterating over?


*Transactions:*

1) We feel strongly that nested transactions should be allowed.  Closed
nested transactions should be simple to implement and will make it much
easier for multiple layers of abstraction to use IndexedDB without knowledge
of each other.

2) In the spec, dynamic transactions and the difference between static and
dynamic are not very well explained.

3) I'm not sure that I like how the spec talks about commits being durable
but then later says "Applications must not assume that committing the
transaction produces an instantaneously durable result. The user agent may
delay flushing data to durable storage until an appropriate time."  It seems
like the language should be made more consistient.  Also, it seems like
there should be some way to ensure it is durable on disk for when it's
absolutely necessary.  (But maybe with a note that UAs are free to rate
limit this.)


*Misc:*

1) Structured clone is going to change over time.  And, realistically, UAs
won't support every type right away anyway.  What do we do when a value is
inserted that we do not support?

2) It seems that you can only be connected to one database at a time?  If
so, why?

3) Do we have enough distinct error codes?  For example, there are multiple
ways to get a NON_TRANSIENT_ERR when creating a transaction.  Error strings
can help with debugging, but they can differ between UAs.  It seems as
though all errors should be diagnosable via the error codes.

4) In 3.3.2, openCursor takes in an optional IDBKeyRange and then an
optional direction.  But what if you don't want a range but you do want a
particular direction?  Are implementations expected to handle this by
looking at whether the first parameter is a IDBKeyRange or not?  Same goes
for IDBIndexSync.

5) Similarly, put takes 2 optionals.  Depending on the object store it may
or may not make sense for there to be a key param.  I guess the javascript
bindings will need to have knowledge of whether a key is expected and/or
disallow boolean keys?  It'd probably be better to avoid this from a
bindings point of view.

3.2.2.4 - why would you skip the next step?
3.2.2.6 - should be preform one or the other, right?
3.2.2.6.1 - should be "if it has a key generator" right?

3.3.2 - if createObjectStore converts a null name to the empty string, why
woudln't openObjectStore, create/open index, and
removeObjectStore/removeIndex?


Thanks,
Jeremy