search

w3c / requestidlecallback

Cooperative Scheduling of Background Tasks
https://w3c.github.io/requestidlecallback/
Other
50 stars 19 forks source link

Define IdleDeadline internal layout part 2 #61

Closed annevk closed 7 years ago

annevk commented 7 years ago

didTimeout is still defined in a weird way.

igrigorik commented 7 years ago

The didTimeout attribute on an IdleDeadline object must return true if the callback was invoked by the invoke idle callback timeout algorithm, and false otherwise. ... The invoke idle callbacks algorithm:

  • Let deadlineArg be a new IdleDeadline. Set the time associated with deadlineArg to deadline and set the didTimeout attribute to false. ...

The invoke idle callback timeout algorithm:

  • Let deadlineArg be a new IdleDeadline. Set the time associated with deadlineArg to now and set the didTimeout attribute to true.

What do we need to clarify here?

annevk commented 7 years ago

You don't want to define an attribute value in terms of whether a callback was invoked. The must requirement doesn't translate to straightforward code.

rmcilroy commented 7 years ago

Would changing it work if we changed the phrasing of the initial sentence to be:

The didTimeout attribute on an IdleDeadline object MUST return true if the callback is being executed outside an idle period due to it having exceeded the timeout passed as an IdleRequestOptions parameter when the callback was registered, and false otherwise

annevk commented 7 years ago

No, you should just define it how it's implemented. IdleDeadline has an associated X, which is initially Y. didTimeout's getter must return X. The callback sets X to Z.

rmcilroy commented 7 years ago

Got it, thanks. Should be addressed in #62. I added some of the text about being executed outside an idle period to clarify the reason for didTimeout after defining it - I can make this a non-normative note if you prefer.

igrigorik commented 7 years ago

Resolved via https://github.com/w3c/requestidlecallback/pull/62.