Re: Draft algorithms specification

Mark, further responses on a few points inline.

On 2015-01-09 03:45, mark a. foltz wrote:
> Francois, thank you for the detailed feedback.  Responses inline, and I
> will craft a PR with some edits shortly.
>
> On Tue, Jan 6, 2015 at 6:34 AM, Francois Daoust <fd@w3.org
> <mailto:fd@w3.org>> wrote:
>
>     Hi Mark,
>
[...]
>     ... And I would replace "7.3 No Screens Available" section by a new
>     one called "Monitor the availability of screens", along the lines of:
>
>     [[
>     When requested to monitor the availability of screens that are
>     compatible with the Presentation API, the user agent must repeat the
>     following steps periodically (say, once every few seconds) while
>     there are event handlers added to
>     NavigatorPresentation.__onavailablechange:
>
>     1. Queue a task to search for screens compatible with the
>     Presentation API
>     2. Wait for the completion of that task
>     3. Let newScreens be the list of available screens found during the
>     search
>     4. If availableScreens is empty and newScreens is not empty, then:
>         1. Queue a task to fire an event named availablechange at all
>     the event handlers added to
>     NavigatorPresentation.__onavailablechange with the event's available
>     property set to true.
>     5. If availableScreens is non empty and newScreens is empty, then:
>         1. Queue a task to fire an event named availablechange at all
>     the event handlers added to
>     NavigatorPresentation.__onavailablechange with the event's available
>     property set to false.
>     6. Set newScreens to availableScreens.
>     ]]
>
>
> Sounds good, although I would slightly alter the text to not require
> periodical searches since that may vary depending on the implementation
> of discovery.  The important detail is to run the algorithm above when
> the set of available screens may have changed for any reason, via
> periodic scan or passive discovery.

Right, I did not really know how to capture passive discovery properly 
in that pseudo-code. Feel free to alter the text in any way you want!


[...]
>     7.5 Join Session
>     -----
>     The current algorithm returns the first matching presentation. If a
>     Web page created two presentation sessions with the same URL and
>     presentation ID for two different second screens, how can it resume
>     the second one?
>
>
> As the algorithm defined the user agent should only allow the page to
> join one of the two presentations; the prose part of the spec reads:
>
>      <p>
>        If the browser knows of multiple matching sessions, it should
> connect the
>        page to the session that was most recently connected to; if that
> cannot
>        be determined by the browser (for example, if the matching
> sessions have
>        never been connected), then the <code>Promise</code> should remain
>        unresolved.
>      </p>
>
> To implement that, we need to keep track of the last connected time for
> each presentation and update the algorithm accordingly.
>
> Instead, if we would like to allow resumption of multiple sessions that
> share a URL+ID, then several changes would be required:
>   - The user agent would need to assign an internal unique identifier to
> each presentation (or to each screen) so it could track them using
> something other than URL+ID.
>   - joinSession() would resolve to an array of PresentationSessions in
> case there were multiple matches.

Perhaps we can leave that as an open issue for the time being and focus 
on main use cases that involve presenting content on only one second 
screen first.

Support for more than one session at once might affect other parts of 
the API. For instance, once a page has already established a first 
presentation session with a second screen, there is currently no way for 
the page to know whether it may create another session with another 
second screen. The "availablechange" mechanism could perhaps be turned 
into a "stillavailablechange" mechanism. Or we may find good reasons to 
let the page say "I want to open sessions with 2 screens if possible" 
right away.


>     7.6 Session Close
>     -----
>     What is the purpose of step 4? Why is it not enough to "queue a task
>     to fire an event named statechange at S.onstatechange" given that S
>     is known right from the start?
>
>
> That was a long winded attempt to ensure that all pages connected to a
> session get the event.  I agree this should be simplified and explained
> that events fired on a PresentationSession are sent to all pages that
> currently hold a reference to it.

Hmm, I assumed there would be only one page holding a reference to a 
session at a time. Is that not the case?

In other words, I thought different tabs would have different sessions 
objects, so that a call to "close" issued in one tab would not have any 
effect on a similar session running on another tab.

By the way, shouldn't closing a session also remove the corresponding 
entry from set D?


Thanks,
Francois.

Received on Friday, 9 January 2015 11:52:22 UTC