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

On Wednesday, March 6, 2013, Glenn Maynard wrote:

> On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell <slightlyoff@google.com<javascript:_e({}, 'cvml', '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.
>

I'm not understanding how this refutes the fact that single-fired events is
an odd model for the job.  Sure it may be consistent, but it's consistently
bad.  There are plenty of criteria for judging an API, one of which is
consistency amongst the rest of the platform idioms.  But it should be no
wonder that solid API developers come along and create comprehensible
wrappers around the platform.


>
>
>>    - *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).
>

I think this would be very desirable on all fronts to avoid duplication of
interfaces; maybe something like signal events on which a caller can wait:

var signal = someAsyncAction(),
      result = signal.wait();

This is an entirely different conversation though.  I don't know the answer
to why sync interfaces are there and expected, except that some would argue
that it makes the code easier to read/write for some devs. Since this is
mirrored throughout other platform APIs, I wouldn't count this as a fault
in IDB specifically.

>
>>    - *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
>
>