W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

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

From: Tim Caswell <tim@creationix.com>
Date: Thu, 17 Apr 2014 15:22:59 -0500
Message-ID: <CAGkHjAV=6-kUZ7vG0impf-SWATTB8kGx59+Nj-td3r=sX=hH9g@mail.gmail.com>
To: Joshua Bell <jsbell@google.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Ali Alabbas <alia@microsoft.com>
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.
>
Received on Thursday, 17 April 2014 20:23:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC