Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

On Fri, Mar 12, 2010 at 3:04 PM, Kris Zyp <kris@sitepen.com> wrote:

>
> Seems like there is a false dichotomy here. I don't think anyone has
> suggested non-event based API. If the IndexedDB is going to have an
> asynchronous interface, clearly the results of operations should be
> made available through events (meaning that results will be enqueued
> on the event loop and handlers will be executed).
>

I didn't realize that the term "callback" precluded the possibility of the
operation being enqueued onto the event loop.  I agree that it should.  To
me, an event based interface is one where you register event handlers for
events.


> I think the question
> is whether to pass in callbacks to the initial function call, or have
> the call return an object (DBRequest object) that allows for
> registration of callbacks.
>

My email was the first time such a proposal for the latter was ever made, as
far as I know, so the way you're phrasing this is awfully odd.  And I think
I gave some good reasons why the latter might not be desirable, but I'm not
totally against it.


> I believe computer science has clearly
> observed the fragility of passing callbacks to the initial function
> since it conflates the concerns of the operation with the asynchronous
> notifications and consequently greatly complicates composability.
>

I don't understand this sentence.  I'm pretty sure that you can wrap any
callback based API in JavaScript with a promised, differed, etc based API.
 As Nikunj mentioned earlier, we're more concerned about creating a small
API surface area and sticking with well understood API designs rather than
eliminating the need for libraries that wrap IndexedDB.


> Apparently, this was also realized in the IndexedDB design, since the
> current spec follows the latter approach and returns a promise-like
> object for callback registration.
>

This is _not_ what's currently specced.  Please take another look.  It
returns an object which has a request attribute.  Future method calls return
their result to the event handler registered there.  This means you cannot
have multiple requests in flight at one time.


> I agree that this is a good design.
> My proposal in regards to the use of CommonJS promises was that rather
> than inventing a new API-specific "DBRequest" interface for this event
> registration, that we should utilize the extensive design and broad
> acceptance behind the CommonJS promise API for handling the event
> registration (which is a much safer design than the DBRequest interface).
>

I really appreciate your feedback while exploring the issue earlier, but I
have to agree with Nikunj's conclusion that we should stick with something
more traditional for IndexedDB for reasons that have already been explained.