Step 11 of getAvailability should not run "in parallel" #381

Activity

1. markafoltz commented on Dec 1, 2016

   

   markafoltz

   on Dec 1, 2016

   Contributor

   More actions

   Agreed.
2. markafoltz commented on Dec 1, 2016

   

   markafoltz

   on Dec 1, 2016

   Contributor

   More actions

   Note that it looks like "in parallel" was added for Issue #335 filed by @schien, to resolve the Promise early.

   The issue seems to be:

   • If monitoring has not run before for the URLs in the request, we should wait until it completes to return a value.
   • If monitoring has run before then we can resolve immediately with a known value, and run it again to refresh the value.

   Practically speaking, I expect that developers will need to add an onchange handler to get correct availability information, so the page will always get the correct value eventually. I guess it's a question of whether they care that the initial value may be based on incomplete information.

   @schien et al what do you think?
3. tidoust commented on Dec 1, 2016

   

   tidoust

   on Dec 1, 2016

   MemberAuthor

   More actions

   If monitoring has not run before for the URLs in the request, we should wait until it completes to return a value.

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

   If monitoring has run before then we can resolve immediately with a known value, and run it again to refresh the value.

   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 (it may still do so given that the spec says it may monitor on a continuous basis but that's not mandated in response to the second call to getAvailability).

   Practically speaking, I expect that developers will need to add an onchange handler to get correct availability information, so the page will always get the correct value eventually. I guess it's a question of whether they care that the initial value may be based on incomplete information.

   I note that could affect tests as well, and @tomoyukilabs raised the question of the "initial value" in:
   web-platform-tests/wpt#4192 (comment)

   I would personally expect that initial value to convey "complete" information, meaning the "same" result as if I had called start instead of getAvailability. In other words, in simple scenarios, 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?

   This is what the test on PresentationAvailability assumes for now.
4. markafoltz commented on Dec 3, 2016

   

   markafoltz

   on Dec 3, 2016

   Contributor

   More actions

   "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 #381 (comment). 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."
5. tidoust

   added a commit that references this issue on Dec 14, 2016

   Issue w3c#387: Monitoring algo now takes pending request to start int…

   ...

   97ee0f6
6. markafoltz

   added a commit that references this issue on Dec 21, 2016

   Issue #387: Monitoring algo takes pending request to start into accou…

   ...

   0c800c5
7. markafoltz commented on Dec 21, 2016

   

   markafoltz

   on Dec 21, 2016

   Contributor

   More actions

   Should be addressed by PR #387.
8. markafoltz

   closed this as completedon Dec 21, 2016