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

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

>  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 
server.disconnect(). 

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 
https://github.com/w3c/presentation-api/pull/390#issuecomment-265300621
 using your GitHub account

Received on Tuesday, 6 December 2016 22:58:33 UTC