- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Oct 2024 23:08:29 +0000
- To: public-secondscreen@w3.org
I reviewed the discussion in the [TAG guidance](https://www.w3.org/2001/tag/doc/promises-guide#state-transitions) and now believe that returning a new Promise is the right thing to do for two reasons. 1. Because browsers can become able or unable to monitor the list of presentation displays in the background, the `getAvailability()` method is a "state transition" case and not a "one time asynchronous function" case in the TAG guidance. 2. With the current algorithm, an app will have no way to monitor availability if the browser becomes able to monitor presentation displays (when it could not before) because the previously-rejected Promise will always be returned. The only way would be to create a new but identical `PresentationRequest`, which is not very intuitive. To implement the full "state transition" guidance and conditionally return existing Promises would add significant complexity to the spec and implementations, because the browser would need to track all of the reasons why monitoring was possible (or not) continuously, and signal the API to behave accordingly on state transitions. In Chrome, there are at least 5-6 reasons I can think of, and some that Chrome can't even know about until it tries to query for compatible devices. I don't support adding this requirement to implementations. -- GitHub Notification of comment by markafoltz Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/507#issuecomment-2394774936 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 October 2024 23:08:30 UTC