Add note on how presentations without connections should be handled.

[markafoltz]

Addresses Issue #202: Presentations without communication channel

This advises user agents on how to handle presentations where the controlling page cannot communicate with the presentation through the Presentation API.

Presumably, the presentation request URL contains sufficient information for the two pages to rendezvous through some other mechanism (if they wish to communicate).

---

Preview | Diff

[markafoltz]

@tidoust, you had the most to say on this long-standing issue :-)

[tidoust]

A couple of comments:

1. Doesn't the note actually contradict the note that's right before it and that says: "The connection must provide a two-way messaging abstraction [...]"?
2. In particular, many apps will expect a communication channel to be available. This note suggests that user agents may not provide one. Isn't that going to break the user experience?

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.

In any case, if there are no implementation plans for such a feature, it should probably just be dropped.

[markafoltz]

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