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

On Fri, Mar 12, 2010 at 3:23 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

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

Apologies, I was sloppy with my terminology: it passes the IDBRequest object
in to the onsuccess callback (not returns)


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