Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell <slightlyoff@google.com> wrote:

> Comments inline. Adding some folks from the IDB team at Google to the
> thread as well as public-webapps.
>

(I don't want to cold CC so many people, and anybody working on an IDB
implementation should be on -webapps already, so I've trimmed the CC to
that.  I'm not subscribed to -tag, so a mail there would probably bounce
anyway.)

>
>    - *Abuse of events*
>    The current IDB design models one-time operations using events. This *
>    can* make sense insofar as events can occur zero or more times in the
>    future, but it's not a natural fit. What does it mean for oncomplete to
>    happen more than once? Is that an error? Are onsuccess and onerror
>    exclusive? Can they both be dispatched for an operation? The API isn't
>    clear. Events don't lead to good design here as they don't encapsulate
>    these concerns. Similarly, event handlers don't chain. This is natural, as
>    they could be invoked multiple times (conceptually), but it's not a good
>    fit for data access. It's great that IDB as async, and events are the
>    existing DOM model for this, but IDB's IDBRequest object is calling out for
>    a different kind of abstraction. I'll submit Futures for the job, but
>    others might work (explicit callback, whatever) so long as they maintain
>    chainability + async.
>
>
I disagree.  DOM events are used this way across the entire platform.
Everybody understands it, it works well, and coming up with something
different can only add more complexity and inconsistency to the platform by
having additional ways to model the same job.  I disagree both that we need
a new way of handling this, and that IDB made a mistake in using the
standard mechanism in an ordinary, well-practiced way.


>    - *Doubled API surface for sync version*
>    I assume I just don't understand why this choice was made, but the
>    explosion of API surface area combined with the conditional availability of
>    this version of the API make it an odd beast (to be charitable).
>
> There's currently no other way to allow an API to be synchronous in
workers but only async in the UI thread.

There was some discussion about a generalized way to allow workers to block
on a message from another thread, which would make it possible to implement
a synchronous shim for any async API in JavaScript.  In theory this could
make it unnecessary for each API to have its own synchronous interface.  It
wouldn't be as convenient, and probably wouldn't be suitable for every API,
but for big, complex interfaces like IDB it might make sense.  There might
also be other ways to express synchronous APIs based on their async
interfaces without having a whole second interface (eg. maybe something
like a method to block until an event is received).


>    - *The idea that this is all going to be wrapped up by libraries anyway
>    *
>
> I don't have an opinion about IDB specifically yet, but I agree that this
is wrong.

People have become so used to using wrappers around APIs that they've come
to think of them as normal, and that we should design APIs assuming people
will keep doing that.

People wrap libraries when they're hard to use, and if they're hard to use
then they're badly designed.  Just because people wrap bad APIs isn't an
excuse for designing more bad APIs.  Wrappers for basic usage are always a
bad thing: you always end up with lots of them, which means everyone is
using different APIs.  When everyone uses the provided APIs directly, we
can all read each others' code and all of our code interoperates much more
naturally.

(As you said, this is only referring to wrappers at the same level of
abstraction, of course, not libraries providing higher-level abstractions.)

-- 
Glenn Maynard