Re: [presentation-api] PresentationReceiver: rename getConnection() and getConnections()

@mounirlamouri Thanks for reminding me of #19 where this API was 
hashed out before.

It looks like I was not a big fan of exposing the full sequence of 
connections to the presenting page (see 
https://github.com/w3c/presentation-api/issues/19#issuecomment-111601625).

>From what I can tell, the arguments for exposing the sequence of 
connections were to allow the presenting page to implement a cap on 
the number of controllers, and possibly to simplify broadcast 
messaging.  Either can be implemented without the sequence however.  
It means presentation has to manage its own Array of connections for 
the multi-controller case.  As we are already under the assumption 
that the multi-controller case is uncommon, I am not too concerned.  
And it can be added later if needed.

In the spirit of moving forward with the minimal viable API, let's go 
with the proposal in 
https://github.com/w3c/presentation-api/issues/201#issuecomment-146212410.
  We would need to nail down the following behaviors:

1. Controller connects while there is no unresolved Promise from 
`waitForNextConnection`.
2. Presentation creates multiple unresolved Promises via 
`waitForNextConnection` while there is no pending connection.
3. When does the connection change state to "connected" on the 
controller?  When it's used to resolve the Promise, or earlier?

For #1 and #2 the presenting UA would maintain a queue of incoming 
connections and Promises and resolve them in order.  For #3 we need to
 either specify a more complete connection handshake, or mandate 
buffering until the presentation is actually to receive messages.

-- 
GitHub Notif of comment by mfoltzgoogle
See 
https://github.com/w3c/presentation-api/issues/201#issuecomment-146346531

Received on Wednesday, 7 October 2015 22:06:49 UTC