[presentation-api] Spec should clarify the initial presentation connection state

tidoust has just created a new issue for 
https://github.com/w3c/presentation-api:

== Spec should clarify the initial presentation connection state ==
Example 5 in the spec (as discussed in #198) currently assumes that 
the initial state of the connection is `closed`, and that it will 
change to `open` afterwards, triggering a `statechange` event.

This matches my reading of the algorithms defined in the spec (which 
"queue a task" at key points to establish the communication channel 
and return the presentation in the meantime).

However, discussions at the F2F suggest that may not be the case.

The specification should be clear about the initial state of the 
presentation object returned when the start promise is resolved, or on
 the lack of guarantee that it has any initial state (for instance, 
because the Web app may check the resolved promise at any time and not
 necessarily as soon as the promise is resolved internally).

Developers need that clarification to know whether they can expect a 
`statechange` event to being with or whether they have to listen to 
the `statechange` event *and* check the initial state, if they want to
 do something with the presentation object when the channel is opened.

See https://github.com/w3c/presentation-api/issues/216

Received on Thursday, 29 October 2015 01:53:55 UTC