[presentation-api] Pull Request: Updates to PR #277 that addresses issues #254, #269, #273

tidoust has just submitted a new pull request for 
https://github.com/w3c/presentation-api:

== Updates to PR #277 that addresses issues #254, #269, #273 ==
This is pull request for the pull request #277...

I have the following comments on PR #277:

1. The definition of the set of availability objects still asserts 
that `availabilityUrl` is the parameter passed to `getAvailability()`.
 That's an old remain of some past version where `getAvailability()` 
indeed took a parameter.
2. Getting the `connectionList` attribute creates a new 
`PresentationConnectionList` instance for each call, whereas I would 
assume we would rather return the same instance each time.
3. Getting the `connectionList` attribute always returns a promise 
that is immediately resolved. I believe the reason why we want a 
Promise in the first place is to ensure that the app gets a 
`connectionList` with at least one presentation connection in it (the 
one that gave birth to the receiving browsing context), so we should 
wait for that to happen, or we should not return a Promise.
4. There should no longer be any need to "start monitoring incoming 
presentation connections" when getting the `connectionList` attribute,
 since that is now done in the "starting a presentation" steps

This PR updates the PR #277 to address each of these points:

1. I dropped "parameter" and used "presentation request URL" instead
2. I added the fact that a `PresentationReceiver` has an associated 
`PresentationConnectionList` object, and that getting the 
`connectionList` attribute resolves the returned promise with that 
object.
3. Getting the `connectionList` attribute now only returns a resolved 
promise if the set of presentation controllers is non empty. The 
promise is resolved when the first `PresentationConnection` object is 
added to the list otherwise (note that the `connectionavailable` event
 is *not* fired when that happens, which seems to be the right thing 
to do).
4. I dropped the step that instructed the user agent to start 
monitoring incoming presentation connections.

For 2., it could be better to find a real `dfn` name for the 
`PresentationConnectionList` object associated with the 
`PresentationReceiver` object, but I could not really come up with a 
good name (we already have "set of presentation controllers", I tried 
"incoming connection reporter" but that looked awkwards).

See https://github.com/w3c/presentation-api/pull/278

Received on Friday, 15 April 2016 11:45:51 UTC