- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 09 Sep 2014 17:25:30 -0700
- To: public-media-capture@w3.org
I've said this before, but.....
is there any reason why getting usermedia with a promise needs to have
the same name as getUserMedia?
If we define a new function called requestUserMedia(), there's zero
compatibility problems.
On 09/09/2014 03:43 PM, Martin Thomson wrote:
> On 9 September 2014 11:02, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> The "transition API" for UAs for the next year: [4]
>> -----------------------------------------------
>>
>> After:
>> callback FooSuccessCallback = void (Bar bar);
>> Promise<Bar> foo (FooSuccessCallback successCallback,
>> CommonErrorCallback errorCallback);
> I think that this is the right approach. More or less. Marking the
> callbacks as optional would seem to be necessary.
>
>> Implementation is easy: we stuff any passed-in callbacks into the .then() of
>> the promise before returning it.
> I think that we need to be more careful about that. Is this what you propose?
>
> foo: function(s, e) {
> return theRealFoo().then(s, e);
> }
>
> The note being here that if the success callback returns void, then
> that's cool. If it returns a promise, then it chains. Do you want
> that? or do you instead want insulation from the callback return
> values? e.g.
>
> foo: function(s, e) {
> return theRealFoo().then(x => { s(x); }, err => { e(err); });
> }
>
>> [4] createOffer is a bit of a challenge with its options argument coming after the callbacks. I'm looking into that.
> Does an overload work?
>
--
Surveillance is pervasive. Go Dark.
Received on Wednesday, 10 September 2014 00:26:09 UTC