Re: [presentation-api] Review the use cases and requirements

Here is the discussion result with @mfoltzgoogle and @avayvod, some 
wording need further refinement:

**Discovery & availability**
    The UA must provide a way to find out whether at least one 
secondary screen is available. (note: think of more than one screen if
 there’s a use case for 1:n case)
    *EDITOR’S NOTE: Spec should clarify that a single physical screen 
may accept multiple presentations.*
**Launching presentation**
    The UA must provide a way to start sending content to one or many 
secondary screens from one or more controlling pages. This may occur 
at the request of the page or at the request of the UA.
Resuming presentation
    The UA must be able to resume an existing session with the content
 being displayed on the secondary screen.
**Communication**
    The UA must enable exchanging data between the primary and the 
secondary screen in order to have a control channel between the 
primary and secondary page. The UA must not make assumptions about the
 execution locality of the UA of the remote page or pages it 
communicates with (i.e. the secondary page or pages might run on one 
or many remote UAs, and thus the link between these two or more pages 
must be loosely coupled).
**Signaling disconnection**
    The UA must signal disconnection from the presentation page to the
 primary page and vice versa.
**Many-to-one session**
    The UA should be able to accept multiple incoming sessions within 
one presentation browsing context. This functionality might not be 
supported in 1-UA mode because the presentation browsing context is 
not shareable across devices.

-- 
GitHub Notif of comment by schien
See 
https://github.com/w3c/presentation-api/issues/68#issuecomment-105367018

Received on Tuesday, 26 May 2015 02:39:19 UTC