W3C home > Mailing lists > Public > public-secondscreen@w3.org > December 2016

[presentation-api] Pull Request: Issue #387: Monitoring algo takes pending request to start into account

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Wed, 14 Dec 2016 12:25:20 +0000
To: public-secondscreen@w3.org
Message-ID: <pull_request.opened-97942406-1481718317-sysbot+gh@w3.org>
tidoust has just submitted a new pull request for 

== Issue #387: Monitoring algo takes pending request to start into 
account ==
This PR is meant to replace PR #390. It implements the changes 
discussed there.

Main changes:

- Prose similar to that used in the Web Bluetooth spec used for the 
garbage collection note for the "presentation display availability" to
 clarify the intent. We may want to adjust this text in #391.
- Notion of "presentation availability promise" dropped. That promise 
is now referenced in `getAvailability` as "an unsettled Promise from a
 previous call to `getAvailability` on `presentationRequest`". This 
avoids having to be explicit about garbage collection rules.
- Step that instructs the UA to run the monitoring algorithm no longer
 runs "in parallel" (see #381)
- Note added next to that step to clarify that the monitoring 
algorithm needs to run again even if it is still running
- The monitoring algorithm now starts by making a shallow copy of the 
"set of presentation availability objects" which gets completed with 
the right tuple if there is a pending call to `start` (note there can 
be at most one such pending call per controlling browsing context)
- Steps that update the `value` property adjusted to set the value 
directly for `PresentationAvailability` objects that have not yet been
 exposed to ECMAScript object. This is triggered by the following 
(new) problem: the `getAvailibility` promise gets resolved with a 
`PresentationAvailability` object as soon as the
monitoring algorithm is done running, but the monitoring algorithm 
"queued a task" to update the `value` property of 
`PresentationAvailability` objects. The `value` property of the 
returned `PresentationAvailability` object would always have been the 
initial value (`false` in most cases), even if the monitoring 
algorithm had found an available display. Also, we probably do not 
want to fire `change` events for properties that JS code has not yet 
been given any chance to read. Here as well, we may want to adjust 
this text in #391.
- The initial `value` of newly created `PresentationAvailability` 
objects is now always `false`. There should be no need to set it to 
`true` given that the monitoring algorithm refreshes that value right 
after that (and given the previous fix).
- I added a note next to the monitoring algorithm to clarify that a 
user agent may interrupt and re-run the algorithm to group requests, 
which seems like a possible optimization.

See https://github.com/w3c/presentation-api/pull/392
Received on Wednesday, 14 December 2016 12:25:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 14 December 2016 12:25:27 UTC