Specify the presentation initialization algorithm

[anssiko]

The latest Editor's Draft needs to define the algorithms for the following:

7.1 The Screen Availability algorithm
7.2 The Start Session algorithm
7.3 The Join Session algorithm
7.4 The Close Session algorithm
7.5 The Presentation Initialization algorithm

http://w3c.github.io/presentation-api/#algorithms

[markafoltz]

Initial versions of 7.1 - 7.4 are present in the current draft. 7.5 remains an open issue.

[anssiko]

Since the initial versions of the screen availability and start/join/close session algorithms have landed, I'm renaming this issue to "Specify the presentation initialization algorithm" to focus the efforts.

[anssiko]

Re the remaining open issue of the initialization algorithm, this is what we're missing:

In http://w3c.github.io/presentation-api/#starting-a-presentation-session we state:

Create a new PresentationSession S

But we do not define the steps the UA is required to take in order to "create a new presentation session". For that, we should add prose to http://w3c.github.io/presentation-api/#presentationsession, like:

When the user agent is to <dfn>create a new presentation session</dfn>, it must instantiate a new PresentationSession object, associate it with XXXX, ... any other normative requirements ..."

(We should then link to this <dfn> definition from the "Starting a presentation session" algorithm.)

I'm tagging this for F2F discussion/review.

All - PRs welcome :-)

[obeletski]

Specification currently defines algorithms that are executed in an opening browsing context for startSession and joinSession methods. I believe that we are missing description of what is happening in the presenting browsing context when those methods are called.

[anssiko]

@obeletski Feel free to take a stab at this. A PR, or a suggestion for the editor to be integrated into the spec would be very welcome. It does not need to be perfect as we can iterate on it.

[tidoust]

PROPOSED RESOLUTION: Promise NavigatorPresentation.getSession() which resolves when the communication channel is established and rejects if the communication channel cannot be established
PROPOSED RESOLUTION: keep the "joinSession" algorithm in 6.4.2 deterministic and strike the issue note about unresolved Promises

See relevant discussion during the F2F in Berlin:
http://www.w3.org/2015/05/19-webscreens-minutes.html#item11

[obeletski]

I would like to share some earlier thinking [1] about initialization of a session in presenting browser context. Even though it is out of date after F2F meeting decisions [2] we might start iterating from it.
We have other relevant issues to cover presentation side session initiation : #52 and #92.

[1] obeletski@ac9e215
[2] http://www.w3.org/2015/05/19-webscreens-minutes.html#item11

[anssiko]

@obeletski I interpret your response as such that it is no objection to the proposed resolution, rather further input. I recall we discussed the merits of using a promise over hanging the session object off of NavigatorPresentation at f2f and landed on the proposed resolution due to that. That discussion was apparently was not minuted. Please let me know if you have concerns.

[obeletski]

I have been doing some work on Presentation API shim that supports multiple controlling page with interface we agreed at F2F meeting. I documented created algorithms for presenting context in commit [1], WDYT?
Unfortunately make failed while generating index.html in xspecxref.py, addReferences, leaving tmp.html in working directory.

[1] obeletski@c373a81

[anssiko]

@obeletski Thanks, your patch seem to build without errors. I suspect you can fix the problem on your local machine by changing your xref repo.