Re: Draft algorithms specification

Hi Mark,

On 2014-12-31 00:04, mark a. foltz wrote:
> Anssi, Dominik, et al,
>
> I have created a first draft of the algorithms [1] to specify the
> behavior of the Presentation API as defined by the current draft of the
> specification [2].
>
> I believe the behavior is consistent with the current state of
> discussion on the mailing list; however, I have annotated the PR with
> several open issues that may deserve further discussion.  If the editors
> and WG members agree with the direction and content of this PR I am
> happy to iterate on it further.

That's a very good step forward!

Here are a few comments:


7.1 Screen Availability Listener Added
-----
I may be reading "searching" the wrong way. I understand it means that 
the search is performed only once, whereas I would rather expect the 
user agent to "monitor" available screens periodically. Or is that intended?

If so, following the current algorithm, a dumb implementation would only 
search for available screens when event handlers are added to 
NavigatorPresentation.onavailablechange. On such a dumb implementation, 
a page that would like to detect whether a second screen becomes 
available after the page has loaded would have to remove then add event 
handlers periodically to trigger a new search. That seems a bad idea. I 
would rather remove the possibility to have dumb implementations in the 
first place.

Said differently, I would replace the current steps with:

[[
Let availableScreens be the list of available screens that are 
compatible with the Presentation API and that are currently known to the 
user agent.

1. If the user agent is not already monitoring the availability of 
screens that are compatible with the Presentation API, then:
     1. Queue a task to monitor the availability of screens that are 
compatible with the Presentation API.
2. If the availableScreens list is not empty, then:
     1. Queue a task to fire an event named availablechange at E (and 
only E) with the event's available property set to true.
]]

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

... along with the current note that the mechanism used to search for 
compatible screens is up to the user agent and that user agents may run 
the monitoring even when there are no event handlers added to 
NavigatorPresentation.onavailablechange.


7.4 Start Session
-----
If the Web app did not use "onavailablechange", the user agent may not 
have searched for available screens yet. I would clarify that 
possibility by replacing step 3 with something along the lines of:

[[
3. If the user agent is not monitoring screens that are compatible with 
the Presentation API, then:
     1. Queue a task to search for screens that are compatible with the 
Presentation API
     2. Wait until that task is completed
4. If last search for screens that are compatible with the Presentation 
API returned an empty list, then:
     1. Reject P with a "NoScreensAvailable" exception
     2. Abort all remaining steps
]]


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?


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?

Also, in the event where a page created two presentation sessions with 
the same URL and presentation ID for two different second screens, 
calling "close" on the first presentation session would trigger a 
"statechange" event on the second one as well, which seems wrong.


7.7 Presentation Connection
-----
Same remark as above for step 3.3.


>
> I am newly acquainted with the indented-list style of pseudocode used by
> the W3C so if anything is unclear please provide feedback here, or in
> conversation on the PR.

Note the style used for pseudo-code is not in any way mandatory within 
W3C. The group may use whatever style it wants, so feel free to propose 
alternatives! That said, it is true that the indented-list style has 
become the norm to define algorithms.

Thanks,
Francois.




> I had some difficulty using the current Makefile to generate cross
> references.  It seems like the content of the xrefs repo in the CG was
> not fully ported to the w3c repo - anolis gives an error when trying to
> process cross references.  Perhaps that can be fixed separately and I
> can rebase my changes so I don't include a hacked up Makefile in my PR.
>
> Cheers and Happy Holidays,
> Mark
>
> [1] https://github.com/w3c/presentation-api/pull/37
> [2] http://w3c.github.io/presentation-api/
>

Received on Tuesday, 6 January 2015 14:35:34 UTC