Re: PeerConnection event queue & "closed" state

On 01/15/2013 05:36 PM, Adam Roach wrote:
> In section 4.3.1, the second numbered list indicates that all calls to 
> the indicated methods enqueue an action without mentioning the current 
> peer state (and the closed state in particular). Since this impacts 
> application-visible behavior (in terms of which method calls trigger 
> callbacks), we want to make sure this is handled consistently among 
> implementations. I think we have three options:
>
>  1. In closed state, continue to queue and process operations
>     (although many, if not all, will fail).
>  2. In closed state, close the queue to new operations, but continue
>     to process any that were enqueued prior to reaching the closed state.
>  3. When transitioning to the closed state, clear the operations queue
>     and close it to new operations.
>
>
> By omitting a discussion of state in section 4.3.1, the current spec 
> implies behavior 1, which is probably not what we intend.
>
> Our current implementation does behavior 2, which has the property -- 
> or at least can be made to have the property -- that any method that 
> typically enqueues an operation either fails immediately, or is 
> guaranteed to trigger a callback at some point in the future.
>
> There is a reasonable argument to be made for option 3 in that an 
> application knows, after closing a PC, that no further operations can 
> be processed, saving it from the need to track state for PCs that 
> cannot form connections. And we could add the property of guaranteeing 
> a callback by specifying that any pending operations have their error 
> callback executed whenever the queue is closed.
>
> My personal preference would be behavior 3 with the error callbacks -- 
> does anyone see a reason to go with either of the other two behaviors?
Off the top of my head, I'd think that behaviour 3 would be consistent - 
at the time of transition, call all the error callbacks with an 
appropriate error - "connection closed"; any later call will throw an 
exception saying "connection closed".

I do think that preserving the property that "if you don't get an 
exception, you'll eventually get a callback" is important.