- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 18 Apr 2014 11:15:29 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Ali Alabbas <alia@microsoft.com>
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