Re: Draft algorithms specification

Inline:

On Fri, Jan 9, 2015 at 3:52 AM, Francois Daoust <fd@w3.org> wrote:

> 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!
>

The text proposed by Dominik looks fine; we might add an implementation
note later to clarify how both passive and active discovery methods are
compatible with the algorithm, and the tradeoff for reliability and latency
vs. efficiency and battery use.


>
> [...]
>
>      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.
>

Sounds good.


>
> 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.


There is nothing preventing a page from requesting multiple sessions now,
although it doesn't have a way to force the user to select a second, unused
screen (or to even know if there is an additional screen available).  You
are correct that we would need to provide more visibility into the status
of all screens to support this use case cleanly.

Do you feel like we should incorporate this question into a new Github
issue?


>
>
>
>      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?
>

That's correct but there could be multiple sessions that are connected to
the same presentation (via join).


>
> 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?
>

Has the semantics of close() been discussed in the CG or WG yet?  It could
mean one of three things:

(1) Disconnect this PresentationSession (and only this PresentationSession)
from the presentation.
(2) Disconnect all PresentationSessions known by this user agent from the
presentation.
(3) Request that the second screen cancel the presentation (and, if
successful, will result in #2).

We can go with (1), which is the most conservative approach, but doesn't
give a page any way to actually stop a presentation itself.  Either the
user agent would  provide a mechanism, or it could message the presentation
document to call window.close().  I'm fine with that approach (it's
consistent with the UX we have for Cast) but I'm curious to hear other
thoughts.

m.


>
>
> Thanks,
> Francois.
>