W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 12 Mar 2010 15:26:01 +0000
Message-ID: <5dd9e5c51003120726x57d36a7buc18c948ae872f06f@mail.gmail.com>
To: Kris Zyp <kris@sitepen.com>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, Jonas Sicking <sicking@mozilla.com>
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.
Received on Friday, 12 March 2010 15:26:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:05 UTC