Re: Concerns about DOMRequest

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.

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.

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

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. 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.
If DOMFuture doesn't keep retro-compatibility, it is not clear why we
should waste cycles creating two new objects with the same intent in
different layers of the Web Platform.

Cheers,
--
Mounir

Received on Wednesday, 13 February 2013 19:57:40 UTC