Re: Requesting display of non HTML content (was: Draft of Second Screen Presentation Working Group Charter available)

Hi Louay,

On Tue, 2014-06-10 at 13:13 +0000, Bassbouss, Louay wrote:


> >We could have a companion project for a helper library
> > like media-presentation.js that provides a JS function like
> > 
> > requestShowMedia("http://example.org/myvideo.mp4")
> > 
> > [...]
> 
> Do you mean the helper js library implements requestShowMedia("http://example.org/myvideo.mp4") using something like this requestShow("http://example.org/wrapper.html") where wrapper.html contains the HTML from above and offer video control over webscreen messaging postMessage() and onMessage()?

Yes, that's what I was trying to suggest.

> > I agree with Louay that the idea is desirable, and with Anssi that this would
> > improve API ergonomics. But I think it has  better place in a library which can
> > evolve faster and more flexibly than a specification.
> > I think we reach our goals quicker if we only provide primitives and let library
> > developers build on top.
> > 
> > If we see certain prominent usage patterns emerge from this example or
> > similar libraries, we can move them to the native side step by step.

> Apple uses just the x-webkit-airplay attribute [1] (possible values are allow or deny) in video elements to enable or disable airplay. Web developers can control and monitor the playback using the standard video functions and events as usual. I we consider this functionality in a programmatic way instead of  declarative way as in apple case, the result will be the same as Anssi proposed. 

Apple only has to solve it for one stack - we might not be able to
implement the same depth of integration, as we're specifiying a common
denominator. That's why I suggest to focus on providing simple
primitives that work reliably, then observe common use cases and iterate
the specification.

Dominik

Received on Monday, 16 June 2014 11:45:33 UTC