Re: [presentation-api] Step 11 of getAvailability should not run "in parallel"

> "In parallel" gives the exact opposite result: it makes the 
monitoring run in the background and thus the promise gets resolved 
immediately (before monitoring is complete). Actually, we would not 
even need a Promise given that all other steps can run synchronously.

Correct, but we'll still need a Promise to be able to notify the 
caller when availability information is known.

> A second call to getAvailability will always return the presentation
 availability promise set during the first call immediately (step 2). 
This aborts the rest of the algorithm. Which means step 11. will not 
run and the user agent is not required to run the monitoring algorithm
 again

Correct, the set of non-empty Availability objects is what requires 
the user agent to monitor continuously, not additional invocations of 
getAvailability().  The existing Promise would be settled with the 
previous result.  So we don't need to worry about the re-invocation 
case.

> I would expect developers to be able to rely on the resolution of 
the Promise without having to listen to the change event. What would 
the Promise convey otherwise?

I agree, and that's what I was proposing in 
https://github.com/w3c/presentation-api/issues/381#issuecomment-264250414.
  And dropping "in parallel" achieves that result.

It's possible that a second availability object is created with the 
same set of URLs as an existing PresentationRequest. In that case, we 
don't need to wait for the monitor steps to complete and can get a 
result from an existing object.  But I think that's an optimization 
that doesn't need to be spelled out in the spec.

Before submitting a PR, I wanted to give @schien a chance to weigh in 
because he filed an issue that added "in parallel."




-- 
GitHub Notification of comment by mfoltzgoogle
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/381#issuecomment-264601129
 using your GitHub account

Received on Saturday, 3 December 2016 00:51:39 UTC