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

Re: [presentation-api] Issue 387: Need to make sure we have a display list for start().

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Mon, 05 Dec 2016 11:27:16 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-264830700-1480937233-sysbot+gh@w3.org>
I see why cleaning up the temporary _presentation availability 
display_ could be useful but, while stupid, cannot an app call 
`getAvailability()` immediately after calling `start()` and before the
 selection algorithm is over? `start()` should not reset _presentation
 display availability_ when it ends in that case because 
`getAvailability` needs it.

This triggers another issue, actually: when can the _presentation 
display availability_ be garbage collected? I read the current 
`getAvailability` algorithm as implying that the _presentation display
 availability_ (and the _presentation availability promise_) are set 
once and for all for the entire duration of the browsing context, and 
thus won't ever be garbage collected.

In turn, this would mean that the garbage collection steps envisioned 
in the [monitoring 
section](http://w3c.github.io/presentation-api/#monitoring-the-list-of-available-presentation-displays)
 will never run: "When a `PresentationAvailability` object is no 
longer alive (i.e., is eligible for garbage collection), the user 
agent SHOULD [...]"... because the availability objects would always 
remain "alive".

Am I reading this correctly? If so, the above GC steps need fixing. If
 not, I think the spec needs to be clearer that the _presentation 
display availability_ and the _presentation availability promise_ may 
be collected at any time (well, the promise must be collected before 
the availability object, since it contains a pointer to it). 




-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/pull/390#issuecomment-264830700
 using your GitHub account
Received on Monday, 5 December 2016 11:27:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 December 2016 11:27:27 UTC