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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


On 3/12/2010 3:17 AM, Jeremy Orlow wrote:
> On Fri, Mar 12, 2010 at 1:05 AM, Shawn Wilsher <sdwilsh@mozilla.com
> <mailto:sdwilsh@mozilla.com>> wrote:
>
>     On 3/5/2010 4:54 AM, Jeremy Orlow wrote:
>
>         For what it's worth, regardless of the answers to the above
>         questions, I
>         think we should switch to a callback based model.  It's
>         great to use
>         events when natural to do so, but this is a very unnatural
>         use.  It
>         provides artificial limitations (only one request in flight
>         at a time,
>         per request object).  It's ugly and confusing syntax wise
>         (hard to keep
>         track of which request object is associated with which
>         request method,
>         requires multiple statements to do each request, requires
>         the handlers
>         to be placed prior to the actual call...which is why the
>         async example
>         in http://www.w3.org/TR/IndexedDB/#introduction is so
>         difficult to read,
>         etc).  And there really isn't any precedent (that I'm aware
>         of) for
>         using events like this.  And the web developers I've spoken
>         to have all
>         been confused by the async API.
>
>     For what it is worth, all the web developers we've talked to
>     have pushed for an event based API, which is why we've been
>     pushing for it.  This happened with the file reader API as I
>     understand it (Jonas or Arun would be able to say more).
>
>     Note that we didn't show them this exact API.
>
>
> I totally believe that, from a high level, an event based API
> is desirable.  When done well, event based models are quite nice
> because they follow the same patterns and are typically easier to
> read.  But I'm not sure if there's a way to make an event based
> model work for IndexedDB.
>
> I suppose you could do something promise-like where each function
> call would return an object that you could register an event on.
>  But syntax wise, that means every method call would require at
> least 3 lines (if you register both an onsuccess and onerror
> handler).  It'd also be a pretty heavy weight solution.
>
> Another possibility is that you could optionally allow the user to
> pass in an identifier to every method call and then pass this in to
> the event.  This would make it possible for the same request object
> to be shared between multiple in-flight requests, but still allow
> the user (or library) to sort out which request got which response.

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


Thanks,

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkuaV/0ACgkQ9VpNnHc4zAzqtACeLlFnjLIEQFMI+I+0rNSeEoAh
r0gAn0VJQUXkCva+84JG5ecACu7GymGU
=vPaD
-----END PGP SIGNATURE-----