- From: Mark Foltz (Google) via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Oct 2020 18:34:45 +0000
- To: public-secondscreen@w3.org
> In other words, I believe that the controlling user agent should never offer to connect to a receiving user agent that wouldn't be able to provide a communication channel, unless the application is explicit that the communication channel is optional (or unless we're talking about a URI scheme different from http and https, but then that's out of scope of the spec). That is the reason why I was proposing some sort of option to the PresentationRequest constructor. I guess you are right, in that this PR doesn't address the problem of availability - the user agent won't know whether to offer receivers without a communication channel, since it won't know in advance whether the application is capable providing its own. > In any case, if there are no implementation plans for such a feature, it should probably just be dropped. We don't have any plans to offer the types of endpoints #3-#6 in Issue #202 (like NFC, BTLE, QR codes) as "presentation" devices through this API. Since the issue was filed, the are Web APIs exposing these capabilities have matured and I think it would make more sense for developers to try those first. I'm going to close this PR and the original issue. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/pull/484#issuecomment-709514990 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 October 2020 18:34:47 UTC