On 05/14/2012 03:55 PM, Jonas Sicking wrote:
I'm not sure where you got the impression that DOMRequest is best
suited for the DOM tree. We currently don't use them anywhere where we
have DOM trees. Likewise, IDBRequest (which basically is a superclass
of DOMRequest) is used all over IndexedDB which isn't connected to DOM
trees. Similarly XMLHttpRequest and FileReader both use events without
using DOM trees.
The behaviour is quite similar to events on regular DOM objects
(document.onload, form.onreset, etc.), but you're right that it is used
in plenty of other places where there is no DOM tree. I had always
perceived the DOMRequest pattern to be useful only when the caller needs
multiple listeners and event bubbling, preventDefault, etc. But it
sounds like you have other reasons to prefer the DOMRequest model...
The problem that I have with callbacks is they aren't very easy to
expand. For example the geolocation API uses a callback to let the
page know about the user's current location. However if you look at
many mapping applications they show an approximate user location which
is gradually refined until a precise location is known. In order to
add this ability to the geolocation API we'd need to add a third
function argument (of which two would be optional) which makes the
signature pretty messy. Likewise, it's hard to add the ability to
cancel a asynchronous request when using the callback style.
That's a pretty compelling reason, thanks for pointing it out.
We could achieve the same with a hybrid approach, which is what the
current getUserMedia spec is doing. Callbacks are only used for error
and success conditions, and everything else is an event. For instance,
the MediaStream object has events for trackadded, trackremoved, etc. and
we can add more in the future.
In general, that's equivalent to the pattern:
apiCall(options, onsuccess, onerror);
onsuccess(obj) { obj.onevent = function(){} ... }
What do you think of this approach?
Thanks,
-Anant
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
