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

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

It seems possible at least given that steps run _in parallel_ each 
time.

> If so, we could have getAvailability() reject if there is an 
unsettled Promise from start()

It seems strange to tie the result of `getAvailability()` to 
`start()`.

> or add a flag to indicate when the temporary availability object may
 cleaned up.

Right, that would solve the problem.

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

I don't remember having seen strong/weak terminology used in other 
specs but maybe I missed something. It is not unusual to see garbage 
collection sections that describe when objects can be collected 
though. I do not know if there is an implicit default that the 
"internal slots" that a spec may use are weak references. It seems a 
good idea to be explicit about the intent in any case.

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

OK, then below is how I would fix this issue and clarify GC behavior. 
Happy to craft a PR if you think that's a good approach.

## In `start()`
Keep the algorithm as it exists today.

If you'd rather continue in the direction you set in this PR, I think 
you need to "synchronize" the `start` and `getAvailability` steps that
 set the _presentation display availability_ and fill out the _set of 
presentation availability objects_, otherwise you could in theory end 
up with duplicate entries in the set. It should be doable by shuffling
 things a bit to move these steps before the algorithms return the 
promise (and thus before algorithms start to run in parallel).

No clean up step should be needed.


## In `getAvailability()`
I think the intent with `getAvailability` is to return the same 
Promise as long as it is unsettled. To be confirmed with @schien (also
 raised in 
https://github.com/w3c/presentation-api/issues/388#issuecomment-264958260).
 If the goal is rather to return the same Promise as long as the code 
holds a reference to a Promise previously returned by that function, 
the suggestion below does not work.

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

1. replace current step 2 with: "If there is an unsettled Promise from
 a previous call to getAvailability on presentationRequest, return 
that Promise and abort these steps". This would make the method return
 the same Promise as long as it is unsettled.
2. adjust steps 3 and 4 accordingly


## In the monitoring algorithm
Start with a couple of steps that clone and extend the _set of 
presentation availability objects_ if needed:

1. Let _availabilitySet_ be a shallow clone of the _set of 
presentation availability objects_
2. If there is a pending request to "select a presentation display" 
for a presentation request and if the _presentation display 
availability_ of that presentation request is null, then create a 
tuple (A, presentationUrls) where presentationUrls are the 
presentation request URLs and add it to _availabilitySet_

Then use _availabilitySet_ in the rest of the algorithm.

An alternative approach would be to craft a separate set of steps for 
the pending request to "select a presentation display" as suggested in
 a previous comment 
(https://github.com/w3c/presentation-api/issues/387#issuecomment-264293136)

Also replace "When a PresentationAvailability object is no longer 
alive" with "When a _presentation display availability_ object is no 
longer alive"


## Next to the definition of presentation display availability
Add a sentence to say that user agents MAY collect the presentation 
display availability for a PresentationRequest at any time when the 
object goes out of scope for the associated script context's scope.


-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/pull/390#issuecomment-265115507
 using your GitHub account

Received on Tuesday, 6 December 2016 10:32:05 UTC