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 10:18
> To: Bassbouss, Louay
> Cc: mark a. foltz; Mark Watson; public-webscreens@w3.org; 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,
> 
> On 16 May 2014, at 10:26, Bassbouss, Louay
> <louay.bassbouss@fokus.fraunhofer.de> wrote:
> 
> > I also think extending the scope of the API to support displaying any web
> content will make it more powerful. From API perspective, the function for
> request show content on second display (requestSession(url)) is easy to
> adapt to any content type (url could point to a html page but also to any
> other web content). My concern is on the control part. In the CG API
> discussion, the communication part is a simple webmessaging-like channel.
> This is applicable when application logic is running on both end-points
> (control and display) but not for content.  For content we need to specify
> control functions for each content type (e.g. for video sess =
> requestSession('example.com/video.mp4'); sess.play(); sess.pause(); etc.).
> > I want just to clarify if this is in scope of the WG and if not, do you imagine
> there is another abstraction level that works for all kind of content?
> 
> 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?

Thanks,
Louay

Received on Tuesday, 20 May 2014 08:57:30 UTC