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: Tue, 06 Dec 2016 22:58:26 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-265300621-1481065104-sysbot+gh@w3.org>
Overall I like the approach you propose, here are a few things I 
noted.  Go ahead with a PR when you are ready.

> Keep the algorithm as it exists today.

Sounds good.

> I propose to get rid of the notion of presentation availability 
promise entirely not to have to worry about specifying GC conditions 
for it:

That would simplify things; but Web developers would need to make sure
 to expunge references to any Promises as well as the resulting 
availability object, in order for the availability object to be 
garbage collected.  This is a valid idiom for Promise-vending APIs, 
and I don't object to it.

> Start with a couple of steps that clone and extend the set of 
presentation availability objects if needed:

Since the monitoring steps run _in parallel_, if `getAvailability()` 
is called while it is running, we would just want to make sure that 
any new availability object created by those steps is inserted into 
the original _set of presentation availability objects_ and not the 
clone; and that the monitoring steps are run again to pick up the new 

>  when the object goes out of scope for the associated script 
context's scope.

This is how Web Bluetooth puts it:

> When no ECMAScript code can observe an instance of 
BluetoothRemoteGATTServer server anymore, the UA SHOULD run 

Or we could just say "is eligible for garbage collection?"

It gets tricky because a script context can have multiple Realms / 
settings objects - so we would need to be specific about which one 
applies.   See Issue #391 I filed.

GitHub Notification of comment by mfoltzgoogle
Please view or discuss this issue at 
 using your GitHub account
Received on Tuesday, 6 December 2016 22:58:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 December 2016 22:58:33 UTC