Initial draft of Open Screen requirements. #14
Conversation
| The Presentation API allows one browser (the *controlling user agent*, or | ||
| *controller*) to discover and initiate presentation of Web content on a second | ||
| user agent (the *receiving user agent*, or *receiver*). We use the term | ||
| *display* to refer the entire device responsible for implementing the |
| *controller*) to discover and initiate presentation of Web content on a second | ||
| user agent (the *receiving user agent*, or *receiver*). We use the term | ||
| *display* to refer the entire device responsible for implementing the | ||
| *receiver*, including browser, OS, networking and display. |
There was a problem hiding this comment.
s/display/screen (looks a bit circular otherwise)
It's a nice definition. Actually, I wonder if we could update the definition of presentation display in the Presentation API to clarify that it refers to "the entire device responsible for implementing the receiver, including browser, OS, networking and screen". Not a big deal, the Presentation API introduction is clear about what constitutes a display in any case.
There was a problem hiding this comment.
Done.
I can check the definition of presentation display in the spec when I take on w3c/presentation-api#345.
| 1. Messages sent by the controller must be delivered to the receiver (or vice | ||
| versa) in a reliable and in-order fashion. | ||
|
|
||
| 2. If a message cannot be delivered, then the controller must be able signal the |
| network transport to the display. | ||
|
|
||
| 3. A controller must be able to determine if the receiver is capable of | ||
| displaying a specific presentation request URL. |
There was a problem hiding this comment.
I note the Presentation API says "reasonably guarantee that the presentation of the URL on that display will succeed". Here, "capable" seems stronger. There may be no way to tell whether a specific presentation request URL can be displayed on top of "yes, I support HTTP" in some cases. Add "reasonably" as well?
There was a problem hiding this comment.
Done - alignment with the spec here should be done as much as possible. Thanks for checking.
|
@schien I broke out the Connections section into separate requirements for initiation, resumption, and other connection requirements. Let me know if that still needs improvement. |
|
Merging, can address additional comments in follow up commits. |
This document addresses part of Issue #1 ([Meta] Write document describing protocol requirements). It has:
This is an initial draft based on some of the content used to develop the charter [1], but streamlined. Any feedback appreciated.
[1] https://github.com/webscreens/cg-charter/blob/gh-pages/requirements.md