Re: Draft of Second Screen Presentation Working Group Charter available (was: Heads-Up: Plan for Working Group on Second Screen Presentation)

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

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 14:57:48 UTC