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

Re: [IndexedDB] Status

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 7 Jun 2010 20:22:37 +0100
Message-ID: <AANLkTilTHh23OUeSYckLDRpzGCuKJ7iqlRXTpUDFqctI@mail.gmail.com>
To: Nikunj Mehta <nikunj@o-micron.com>
Cc: public-webapps WG <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>
Thanks for the update, Nikunj!  Comments inline.

On Mon, Jun 7, 2010 at 6:58 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:

> Art asked for a status update on the IndexedDB spec. Here's my summary of
> the status:
>
> 1. Last published working draft: Jan 5, 2010
> 2. Bugzilla status: 15 issues logged
> 3. Editors: Nikunj Mehta (Invited Expert), Eliot Graf (Microsoft)
> 4. Spec document management: Currently W3C CVS, also using W3C's
> Distributed CVS (Mercurial) system
>

The current spec is really far out of date at this point.  There are 15
issues logged, but I could easily log another 15 (if I thought that'd help
get things resolved more quickly).

I know Eliot is helping out with copy editing, but it's going to take a lot
of time to get the spec to where it needs to be.  Andrei P (of GeoLocation
spec fame) has been working on implementing IndexedDB in Chrome for a couple
weeks now and has volunteered to start updating the spec right away.  He
already has CVS access.  Is there any reason for him not to start working
through the bug list?


> Major discussions since last working draft and their impact on the spec:
>
> 1. Asynchronous API proposal by Mozilla - to be assimilated in to the spec
> 2. Key data type changes proposal by Google - needs some coordination
> within WebApps with the WebIDL spec
>

(Not that it matters, but for the record I believe it was Microsoft/Pablo
who first brought this up, but I think we're pretty much all in agreement
about what needs to be done.)


> 3. Key path specification - no work done yet
> 4. Interaction between transactions - no work done yet
> 5. Version number discussion - no significant changes expected
>
> Here's the sequence in which I will be working with Eliot to add bug fixes
> and the results of recent discussions to the spec:
>
> 1. 9561, 9563, 9768, 9769 - Mozilla Asynchronous API proposal
> 2. 9793: Key data type changes
> 3. 9832: Key path specification changes
> 4. 9789, 9791, 9790 - Naming changes
> 5. 9739 - editorial changes
> 6. 9653 - Null handling
> 7. 9786 - WebIDL bugs
> 8. 9652 - database open changes
> 9. 9796 - async interface in workers
>

Personally I would put #4 and #9 first since both are quite trivial changes
but both are quite important.

The former is important because it helps readability.  Given that the spec
is about the only documentation in existence for IndexedDB, any early
developer feedback we get will be from people who have read the spec.  I've
already talked to developers who were curious about the spec, but gave up on
reading it--partially because of the names being confusing.

The latter is important because it involves changing the way you access the
existing synchronous interface (but is a <5min change to make).  (The
problem is that window.indexedDB is the async interface and
workerUtils.indexedDB is the sync.  The latter should be renamed so that
workerUtils.indexedDB can mean the async interface whether your in a worker
or not.)

Otherwise, the ordering seems good.


> Here are some asks for additions to the spec, which also will need some
> amount of voting in order to be prioritized appropriately:
>
> 1. Nested transactions without durability of partially committed
> transaction trees
> 2. Inverted indexes for supporting full text searching
> 3. Enumeration of databases
> 4. Structured clone dependence
> 5. Encryption and expiration
>

I think these are already pretty well ordered in terms of priority.

Thanks,
Jeremy

[1] http://code.google.com/p/indexeddb/
Received on Monday, 7 June 2010 19:23:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT