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

[presentation-api] new commits pushed by mfoltzgoogle

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Dec 2016 19:39:36 +0000
To: public-secondscreen@w3.org
Message-ID: <push-0c800c5c5bee2573735e4b75b117bca77937a0d9-1482349172-sysbot+gh@w3.org>

The following commits were just pushed by mfoltzgoogle to 
https://github.com/w3c/presentation-api:

* Issue #387: Monitoring algo takes pending request to start into 
account (#392)

* Issue #387: Monitoring algo now takes pending request to start into 
account

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.

* Issue #387: Use availabilitySet in the monitoring algorithm

The variable is obviously useless if it is not referenced. This should
 have
been part of previous commit.

* Issue #387: drop "exposed to JS" and allow monitoring aggregation

This commit drops the fuzzy "exposed to ECMAScript" wording in the 
monitoring
algorithm, and replaces it with a more common "initialized" concept. 
The notion
is clarified in an editorial note next to the step that uses it.

The editorial note that follows the monitoring algorithm was also 
complete to
mention that user agents may aggregate monitoring activities across 
browsing
contexts.

* Issue #387: Update notes with @mfoltzgoogle suggestions
  by Fran├žois Daoust
https://github.com/w3c/presentation-api/commit/0c800c5c5bee2573735e4b75b117bca77937a0d9
Received on Wednesday, 21 December 2016 19:39:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 December 2016 19:39:43 UTC