W3C home > Mailing lists > Public > public-sysapps@w3.org > February 2013

Re: Concerns about DOMRequest

From: Marcos Caceres <w3c@marcosc.com>
Date: Thu, 14 Feb 2013 12:35:02 +0000
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mounir Lamouri <mounir@lamouri.fr>, public-sysapps@w3.org, Alex Russell <slightlyoff@google.com>
Message-ID: <9DF337338E0E4237AB017C83A019A510@marcosc.com>



On Thursday, 14 February 2013 at 11:17, Anne van Kesteren wrote:

> On Wed, Feb 13, 2013 at 8:27 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > It would still really suck if you added .then() but still required everything to be wrapped in a function.
>  
> What do you mean by this?

In IDB, the design of the API forces a developer to do everything synchronously, even though the IDB operation is async in the background (you have to start an operation before you can set listeners on it - so developer are forced to do everything in one go inside a function). See the following, for example:  
http://www.html5rocks.com/en/tutorials/indexeddb/todo/#toc-step2

As already noted, this is just one thing in a long list of things wrong with the IDBRequest/DOMRequest design.  

> > > A promise object in the Web Platform seems to be something that
> > > everybody wants but it is not clear that having it added in the DOM is
> > > the best way to do it.
> > > Having a Future object in Javascript would very
> > > likely be better and last I've heard, Alex's plans were to push for
> > > DOMFuture and for a Future object in Javascript.
> >  
> >  
> >  
> > Alex?... Anne? … Bueller?
>  
> The plan is to have at least a subset in JavaScript. That would also
> allow some more meaningful interfaces (e.g. Future<Blob>). I don't
> think it really matters much where we define this though, we just need
> to agree on the specifics and move on.

Sounds good.  
> > We shouldn't continue to propagate this design from one API when we have others that do
> > async stuff better (e.g., XHR, even Geolocation's callbacks).
>  
> I think Future gives a much better API for both of those. Future is
> great for any kind of async yes/no API.
>  

I hope so. I'm looking forward to playing with Alex's prollyfill of it.  
Received on Thursday, 14 February 2013 12:35:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2013 12:35:38 GMT