W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2015

Re: Need guidance on promise-returning methods on a stateful object

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 19 Oct 2015 15:54:01 -0400
To: Domenic Denicola <d@domenic.me>, Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <56254A59.6060700@mozilla.com>
On 10/16/15 1:05 PM, Domenic Denicola wrote:
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
>
>> In the WebRTC 1.0 spec we have some promise-returning methods on a
>> stateful object (RTCPeerConnection). I would like guidance on how to
>> behave when the instance, on which a method is called, goes into a closed
>> state while an async operation is doing its work. When done, should the
>> promise be rejected, or should we just leave it pending. Note that the script
>> will be informed about the state change through other mechanisms.

(Jumping in. Adam, please correct me if I mess up the answers.)

> A few questions that might help guide us:
>
> - Once the instance goes to a closed state, is it possible for the async operation to ever complete successfully?

No.

> - Once the instance goes to a closed state, would you say that the async operation has now failed?

I suppose, though it seems odd to say that since the operation is no 
longer relevant (what it would have produced would be obsolete).

> - Is the instance going in to a closed state while this async operation is ongoing an "exceptional" condition?

Mostly no, since content can call .close() at any time, and that's the 
typical reason.

I say "mostly" because of an ugly exception: A failed negotiation 
rollback throws InternalError and transitions to closed right after. A 
wort (spec bug?) I wouldn't base design decisions on.

> - Is the instance going in to a closed state while this async operation is ongoing the result of author coding error?

No, with the above-mentioned exception.

.: Jan-Ivar :.
Received on Monday, 19 October 2015 19:54:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 October 2015 19:54:34 UTC