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

Hi Anssi, All,

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Dienstag, 20. Mai 2014 14:20
> To: Bassbouss, Louay; mark a. foltz; public-webscreens@w3.org
> Cc: Mark Watson; Philipp Hoschka; Daniel Davis
> Subject: Re: Draft of Second Screen Presentation Working Group Charter
> available (was: Heads-Up: Plan for Working Group on Second Screen
> Presentation)
> 
> 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');
I understand and agree if the url of requestSession points to an Html document and not to other content types. The background of my question was related to the discussion about considering existing media rendering devices like UPnP/DLNA MediaRenderer that can consume media content without further processing on the control device.  

> 
> ... 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?
> 
> Thanks,
> 
> -Anssi

Received on Tuesday, 20 May 2014 12:36:55 UTC