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

My IndexedDB wishlist:

Ability to enumerate databases, I dont particularly want or care about the
transactional integrity of the api, if someone deletes a database while I
am in a callback in which I think it exists, meh

Change events / Observers, right now I have to fake it via localstorage

A transactional model that isnt tied to the event loop, sometimes I want to
do async things inside the transaction like converting to an ArrayBuffer
etc, I would like to open with an option to have the transaction stay open
till its explicitly closed

No features that slow it down, as with Tim I also implemented the same
thing in node.js and see much better perfomance against straight leveldb,
with websql still being ~5x faster than idb

I dont have any concrete suggestions, but making the transactional states
more visible would help, I have seen pretty much everyone errantly use
.put().onsuccess(function() { yay do stuff, to either lose data by assuming
the write is completed or get in a confusing state trying to open new
transactions. (see step 3 -
http://www.html5rocks.com/en/tutorials/indexeddb/todo/)

I think its also worth (and fairly trivial) to implement sugar syntax for a
key value storage like https://github.com/mozilla/localForage, as a large
amount of usage I have seen just wants to store some simple data and not
deal with transactions, object stores and schema migrations

Cheers
Dale



On 17 April 2014 21:22, Tim Caswell <tim@creationix.com> wrote:

> Personally, the main thing I want to see is expose simpler and lower level
> APIs.  For my uses (backend to git server), the leveldb API is plenty
> powerful.  Most of the time I'm using IndexedDB, I'm getting frustrated
> because it's way more complex than I need and gets in the way and slows
> things down.
>
> Would it make sense to standardize on a simpler set of APIs similar to
> what levelDB offers and expose that in addition to what indexedDB currently
> exposes?  Or would this make sense as a new API apart from IDB?
>
> As a JS developer, I'd much rather see fast, simple, yet powerful
> primitives over application-level databases with indexes and transactions
> baked in.  Chrome implements IDB on top of LevelDB, so it has just enough
> primitives to make more complex systems.
>
> But for applications like mine that use immutable storage and hashes for
> all lookups don't need or want the advanced features added on top.  IDB is
> a serious performance bottleneck in my apps and when using LevelDB in
> node.js, my same logic runs a *lot* faster and using a lot less code.
>
> -Tim Caswell
>
>
> On Wed, Apr 16, 2014 at 1:49 PM, Joshua Bell <jsbell@google.com> wrote:
>
>> At the April 2014 WebApps WG F2F [1] there was general agreement that
>> moving forward with an Indexed Database "v2" spec was a good idea. Ali
>> Alabbas (Microsoft) has volunteered to co-edit the spec with me.
>> Maintaining compatibility is the highest priority; this will not break the
>> existing API.
>>
>> We've been tracking additional features for quite some time now, both on
>> the wiki [2] and bug tracker [3]. Several are very straightforward
>> (continuePrimaryKey, batch gets, binary keys, ...) and have already been
>> implemented in some user agents, and it will be helpful to document these.
>> Others proposals (URLs, Promises, full text search, ...) are much more
>> complex and will require additional implementation feedback; we plan to add
>> features to the v2 spec based on implementer acceptance.
>>
>> 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?
>>
>> If there's anything you think is missing from the wiki [2], or want to
>> comment on the importance of a particular feature, please call it out -
>> replying here is great. This will help implementers decide what work to
>> prioritize, which will drive the spec work. We'd also like to keep the v2
>> cycle shorter than the v1 cycle was, so timely feedback is appreciated -
>> there's always room for a "v3".
>>
>> [1] http://www.w3.org/2014/04/10-webapps-minutes.html
>> [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
>> [3]
>> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
>>
>> PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation
>> report, also presented at the F2F.
>>
>
>