Skip to content

define the behavior for consecutive |getAvailability| #335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
schien opened this issue Aug 30, 2016 · 2 comments
Closed

define the behavior for consecutive |getAvailability| #335

schien opened this issue Aug 30, 2016 · 2 comments
Labels

Comments

@schien
Copy link
Contributor

schien commented Aug 30, 2016

Three unclear behavior found while implementing the |getAvailability| algorithm:

  1. In step 6, the same availability object is returned if an existed (A, presentationUrls) tuple is found. However, we can only return the same object if the requester is in the same DOM window.
  2. in step 9, we should run the device monitoring algorithm in parallel so that we can resolve the promise as early as possible.
  3. For consecutive |getAvailability| on the same PresentationRequest object, we should guarantee the resolve order in the algorithm. For example,
request.getAvailability().then(function() {console.log(1)});
request.getAvailability().then(function() {console.log(2)});

should always print "12" in console for all browsers.

@anssiko anssiko added the v1 label Sep 7, 2016
@tidoust
Copy link
Member

tidoust commented Sep 26, 2016

See discussion at TPAC

PROPOSED RESOLUTION: For #335, check algorithms around availability objects and make sure they all refer to "script object" or "internal object". For bullet 2, add "in parallel" in step 9. For bullet 3, make sure getAvailability returns the same Promise object.

@markafoltz
Copy link
Contributor

Section 6.4 will need a bit of cleanup to make it consistent with reasonable behavior. Here is what I am thinking.

  • Annotate getAvailability() with SameObject.
  • Define a presentation availability internal object for use in the algorithms. There is exactly one of these for a given list of URLs regardless of the script context.
  • Define a presentation availability promise which is created at most once per presentation availability.
  • Make sure that only one PresentationAvailability is created per script context per presentation availability. (This is an optimization, may not be strictly required.)
  • Update conditions when an entry can be removed from the set of availability objects.

Can start after the PR for Issue #342 lands (which tweaks some text in this same section).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants