Re: Starting work on Indexed DB v2 spec - feedback wanted

On Wed, Apr 16, 2014 at 11:49 AM, Joshua Bell <jsbell@google.com> wrote:
> This is an informal call for feedback to implementers on what is missing
> from v1:
>
> * What features and functionality do you see as important to include?
> * How would you prioritize the features?

These are somewhat ordered in terms of priority, which is correlated
to the value/amount-of-work-to-make-it-happen ratio:

1.
At the top of my list is change events. The fact that people end up
using localStorage to circumvent the lack of this is sort of ironic
given that one of the goals of IDB was to avoid synchronous IO :-)

I'm happy to write up a proposal for this.

2.
Some low hanging API fruit. Like ObjectStore/Index.getAll,
ObjectStore/Index.getAllKeys and ObjectStore.openKeyCursor. Again,
happy to write up a proposal for these though they are probably simple
enough that a proposal might not be needed.

3.
Ability to start and continue an index cursor to a specific primary
key. Possibly even create a key range which specifies both index and
primary key for both endpoints.

4.
Localized sorting. At least the ability to sort an index user-locale
order. But probably also the ability to sort an index in a page
specified order.

5.
Expression indexes. Lots of cool stuff here. Such as creating indexes
on the result of a JS expression. And the ability to create an index
on the result of a map-reduce of an objectStore. Maybe even being able
to get all records that match an expression or update all records
using an expression, though here be dragons with footguns.

A big missing piece here though is a JS primitive representing a piece
of code which can be run side effect free in an efficient way. The
only thing we have right now is taking a string which is eval()ed in a
new global each time, which is both awkward development-wise and
expensive CPU-wise.

This is something that we at mozilla will look into, but I can't
promise any results given that we might need to add new JS language
features in order to make this really good.

6.
Promisification. This sounds a lot simpler than it is given that
IndexedDB currently relies quite heavily on the exact timing of when
result callbacks are executed. This is especially relied on in order
to get the auto-comitting transaction behavior to work, which is
sometimes good and sometimes bad.

And we also use event propagation (event paths) for catching errors in
central locations while still allowing those errors to be handled and
the rest of database operations run.

The current API also enables, and tries to encourage, developers to
fire off multiple operations at once and then wait for all of them to
have finished. This offers performance advantages over starting
operations one at a time and waiting for each to finish before
starting the next.

All of this is probably possible to maintain even with promises.
Possibly promises can even solve it better. And obviously the syntax
would be better with promises. But it's not immediately clear to me
how to do it. But if someone does the work of putting together a
working proposal then I'd be all for it.

/ Jonas

Received on Friday, 18 April 2014 18:16:27 UTC