- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Tue, 20 May 2014 16:23:49 +0000
- To: Mark Watson <watsonm@netflix.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- CC: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "mark a. foltz" <mfoltz@google.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Philipp Hoschka <ph@w3.org>, Daniel Davis <ddavis@w3.org>
On 5/20/14, 8:57 AM, "Mark Watson" <watsonm@netflix.com> wrote: >Sent from my iPhone > >> On May 20, 2014, at 5:20 AM, "Kostiainen, Anssi" >><anssi.kostiainen@intel.com> wrote: >> >> Hi Louay, MarkF, All, >> >> On 20 May 2014, at 11:56, Bassbouss, Louay >><louay.bassbouss@fokus.fraunhofer.de> wrote: >> >>>> -----Original Message----- >>>> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] >>>> >>>> I feel media-specific control functions are out of scope for the API, >>>>and I'd >>>> expect such functionality will be provided by JavaScript libraries >>>>build atop >>>> the API. >>> >>> I am not sure if we could provide an abstract function in the >>>Presentation API that can be used from JavaScript libraries build atop >>>to control the content. Since the Presentation API abstracts away from >>>technologies used behind, the control part needs also to be abstract. >>>There are two abstraction options in my point of view: The first >>>option is to specify control functions for each content type and the >>>second option is to offer a messaging channel to the rendering service >>>on the second display: in this case additional information about the >>>communication protocol are needed (if Airplay --> exchange Airplay >>>Messages, if UPnP --> exchange UPnP messages). first option is hard for >>>specification and second option doesn't fit with our API design and >>>Security requirements. >>> @MarkA: Google proposed this feature could you please give a short >>>example how to control e.g. video content? >> >> Loya - herešs a bit more elaborate explanation that hopefully clarifies. >> >> MarkF - does this align with your thinking? >> >> In order to be able to use "common web technologies for messaging >>between the authorized pages and the web content shown on the secondary >>display˛ the URL we pass to the requestSession() or requestShow() must >>point to a document that is transmitted with the text/html MIME type and >>can be processed as an HTML document by either: >> >> 1) the initiating User Agent, or >> 2) the remote User Agent >> >> It is up to the initiating User Agent implementation to decide whether >>it should process the HTML itself or delegate the task to the remote >>User Agent. >> >> For example, if the remote device (e.g. a display connected via HDMI) >>is not able to understand HTML, then the initiating User Agent will >>process the HTML document, render the HTML, convert the rendering into >>video, and send it to the remote device for display. >> >> After either (1) or (2) has fetched and parsed the HTML document, an >>in-memory representation (i.e. the DOM) of the HTML document is created, >>and Web APIs can then be used to interact with this in-memory >>representation. For example, to communicate with the initiating page, >>control playback of the embedded media etc. >> >> The HTML document (foo.html below) may embed video, audio etc. >>(<video>, <audio>) or other application-specific media (<object>, >><embed>). >> >> The HTML spec specifies how to process HTML documents, embed media and >>so forth. Similarly, therešs a spec for web messaging we may reuse >>and/or extend. We donšt need to respecify those aspects in this API. >> >> In other words, the API would support: >> >> requestSession(http://example.org/foo.html'); >> >> Where foo.html is as follows: >> >> <!DOCTYPE html> >> <html> >> <head> >> <title>Foo</title> >> </head> >> <body> >> <video src="http://example.org/foo.mp4˛ autoplay></video> >> </body> >> </html> >> >> [ In a real-world scenario, you would likely implement also your own >>media-specific control functions and use web messaging. For a primitive >>example, see: >> http://webscreens.github.io/presentation-api/#video-and-image-sharing ] >> >> For MIME types other than text/html the API would fail. For example, >>the following would not work: >> >> requestSession(http://example.org/foo.mp4'); >> >> ... as this would require us to expose implementation details of >>connection technologies as you noted in order to be able to control the >>content. >> >> All - do you agree that what is described above is a reasonable scope >>for the API? > >No. User Agents should be able to support protocols such as DIAL The proposal that the URL always references an HTML document does fit within DIAL, doesnšt it? It just presumes there is only one type of DIAL app that can be launched, a browser, which is implicitly identified by the URL that references an HTML page. This approach resolves the desire raised previously to only display availability of secondary devices that support the desired app; there is only one app - a UA. > which >enable discovery of apps on remote devices which are capable of >rendering particular content types or services. In such a case the UA >can hand off rendering of URLs that do not resolve to html documents >to such apps. So in this case, the URL is identifying an application and, potentially, a media item? The discovered second screens displayed to the user should then only be the ones that support the application, right? Bob > >The messaging protocol with such an app would be app-specific, but >this is no different than the case of one web page communicating with >another rendered on a remote UA. > >...Mark > >> >> Thanks, >> >> -Anssi >
Received on Tuesday, 20 May 2014 16:24:27 UTC