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: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Mon, 05 Dec 2016 19:44:09 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-264955764-1480967047-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.

Is it possible for the `getAvailability()` steps to occur during the 
`start()` steps and before the _Cleanup_ step?

If so, we could have `getAvailability()` reject if there is an 
unsettled Promise from `start()`, or add a flag to indicate when the 
temporary availability object may cleaned up.

> 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.

Association of an availability object with a request shouldn't create 
a strong reference for the purposes of GC.  It's to prevent creation 
of duplicate objects.  How do specs label kinds of ownership of 
objects for GC purposes?

> 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).

They should be collected like any other object, when they go out of 
scope for the associated script context's scope.  We should be more 
specific about the relationships among these objects so GC behavior is

GitHub Notification of comment by mfoltzgoogle
Please view or discuss this issue at 
 using your GitHub account
Received on Monday, 5 December 2016 19:44:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 December 2016 19:44:29 UTC