- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Dec 2016 11:27:16 +0000
- To: public-secondscreen@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