[presentation-api] Wrong use of "Queue a task" and "in parallel" in algorithms

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

== Wrong use of "Queue a task" and "in parallel" in algorithms ==
I believe that some of the algorithms in the spec use "Queue a task" 
incorrectly.

"Queue a task" is strongly tied to the event loop:
http://www.w3.org/TR/html5/webappapis.html#queue-a-task
[[ When a user agent is to queue a task, it must add the given task to
 one of the task queues of the relevant event loop ]]

In particular, a task queued on the event loop does not run in the 
background and actually blocks the event loop and thus user 
interactions. However, there are several places in the specification 
where "Queue a task" seems used to mean something like "run the task 
in the background".

For example, in the `start` algorithm:
http://w3c.github.io/presentation-api/#dom-presentationrequest-start

[[ 9. Queue a task C to run the following steps:
  1. Create a receiving browsing context on D and let R be the result.
 
  2. Navigate R to presentationUrl. ]]

Steps 9.1 and 9.2 do not have anything to do with the event loop of 
the current browsing context. Actually, there should be no need to use
 any particular keyword to introduce these steps: that part of the 
algorithm runs in the background already (since the algorithm returned
 the Promise to the calling script at step 4).

Same thing for substeps of step 3. in the `reconnect` algorithm that 
do not have anything to do with the event loop either, I think:
http://w3c.github.io/presentation-api/#dom-presentationrequest-reconnect
[[ 2. Return P.
3. Queue a task T to run the following steps in order: [...] ]]


This algorithm also returns at step 2, so remaining steps de facto run
 in the background. In fact, it would be a good idea to say so 
explicitly whenever we have a "Return" statement in the middle of an 
algorithm by saying "Return P and run the following steps in parallel"
 as done in other specs.

Which brings me to my second point: the `start` algorithm uses "in 
parallel" to mean "run the two following steps in two separate 
background processes", but "in parallel" is now used in other specs to
 mean:
https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel
[[ Some algorithms run in parallel; this means that the algorithm's 
subsequent steps are to be run, **one after another**, at the same 
time as other logic in the specification ]]

Step 5. in the `start` algorithm looks weird as a result, because I 
understand we want to run 5.1 and 5.2 as separate background tasks, 
while the definition suggests that they will be run in the background 
but in order:
[[5. Run the following steps in parallel:
  1. Monitor the list of available presentation displays. 
  2. Queue a task T to request user permission for the use of a 
presentation display and selection of one presentation display.]]

(There's another misuse of "Queue a task" here, as requesting user 
permission is also not tied to the event loop).

I think the easiest way would be to let these two tasks run one after 
the other and update the "Monitor the list of available presentation 
displays" algorithm to say that it runs "in parallel".

Or are there good reasons why steps need to be queued as tasks?
If not, I suggest we merge the pending PR #227 that updates some of 
the algorithms first. I'd be happy to work on a PR afterwards.

Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/231 using your GitHub 
account

Received on Thursday, 17 December 2015 14:09:20 UTC