Re: Promises (Re: New Editor's Draft of MediaStream Image Capture)

On 9/9/14 8:25 PM, Harald Alvestrand wrote:
> I've said this before, but.....
>
> is there any reason why getting usermedia with a promise needs to have
> the same name as getUserMedia?

No technical reason, no.

> If we define a new function called requestUserMedia(), there's zero
> compatibility problems.

Except there's zero compatibility problems with overloading the existing 
function as well, since it returns void, and callback args can be made 
optional.

createOffer is the only tricky one, but it should work too.

> 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?

Short answer, yes, we can deal with it. It's not as pretty as I'd like 
because of [1], but totally doable as a temporary UA measure.

.: Jan-Ivar :.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640

Received on Wednesday, 10 September 2014 14:08:11 UTC