Re: Concerns about DOMRequest

(cc'ing the horses, so we can hear it from them where DOMFuture is going to go...)  

On Wednesday, 13 February 2013 at 19:57, Mounir Lamouri wrote:

> On 13/02/13 18:41, Marcos Caceres wrote:
> > I would kindly request that the group only use this pattern, if, and when, absolutely necessary - or consider better patterns like the one used by XHR, promises, or the DOMFuture proposal [4] (which will soon be merged into DOM4). If the APIs need asynchronous execution, then the most appropriate pattern should be considered on a case-by-case basis, not taken wholesale.
>  
> It's been a few months since we [Jonas and I] are thinking about
> upgrading DOMRequest to a more promise-like design. The recent DOMFuture
> project from Alex Russel made use move a bit in that direction and I
> started implementing some stuff for DOMRequest to be more promise-like.
>  
> However, DOMFuture and DOMRequest are in no way incompatible. The main
> things that we should add to DOMRequest to make them more promise-like
> is a .then() method. We can add a .done() method easily after that (if
> people like it), and a .when() method too I guess.

There are other issues with the design. Apart from the execution sequence: the semantics of DOMRequest are all screwy in that it uses errors as events, etc. and forces everything to be wrapped in a function. It would still really suck if you added .then() but still required everything to be wrapped in a function. Can we please work on this collectively with the ES guys + Alex + Annevk + Yehuda, and maybe even Rick Waldron etc. and come up with something neat (i.e., instead of you guys doing it on your own, pretty please!).    
> The main reason why DOMFuture wouldn't be able to inherits easily from
> DOMRequest is that some names are not the same: result became value and
> success event became accept for example. I understand this is likely
> following the common patterns for promises in Javascript but that breaks
> the Web retro-compatibility.

It only breaks for one API (IndexedDB) and that API was designed to have developers build libraries on top of it. Given that IndexedDB is unusable (by design) by average developers, then breaking compatibility is not that bad a thing. And it's not really "breaking compatibility", it's just using a better design without the usability flaws of IDBRequest.      
> This is the main reason why DOMRequest has been designed like that
> actually: it is compatible with IDBRequest. If we improve DOMRequest to
> have a promise-like interface and change the IndexedDB specification to
> have IDBRequest inheriting from DOMRequest we can improve the Web
> Platform more generally. (You might argue that IndexedDB isn't the most
> important part of it.)

It's going to take more than that to make IndexedDB usable by average devs [like me] (not because the features suck, because IndexedDB is very low level). Hence, it should not be a priority for us to fix that, at least not here: we should make it a priority that these SysApps APIs are actually liked/usable by Web Developers.   
> 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?
> If we do that, I
> believe that keeping DOMFuture (or whatever the name is) compatible with
> what already exist (IDBRequest and somewhat DOMRequest) would be better.

Sure, but we should do what is best for developers and not just to keep compat with an API developers don't interact with directly.  
> If DOMFuture doesn't keep retro-compatibility,

I'm sorry, but this is a red herring. 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).  
> it is not clear why we
> should waste cycles creating two new objects with the same intent in
> different layers of the Web Platform.

Because we don't want to have another army of developers screening "THIS SUCKS" :) If we can't salvage IDBRequest right now, too bad. But we shouldn't make all these APIs suck because IDBRequest sucks.  

--  
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 13 February 2013 20:27:44 UTC