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