- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Mon, 16 Jun 2014 11:59:52 +0000
- To: "Rottsches, Dominik" <dominik.rottsches@intel.com>
- CC: "B.Lund@cablelabs.com" <B.Lund@cablelabs.com>, "watsonm@netflix.com" <watsonm@netflix.com>, "fd@w3.org" <fd@w3.org>, "markdavidscott@google.com" <markdavidscott@google.com>, "mfoltz@google.com" <mfoltz@google.com>, "ddavis@w3.org" <ddavis@w3.org>, "ph@w3.org" <ph@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
Hi Dominik,
> From: Rottsches, Dominik [mailto:dominik.rottsches@intel.com]
> Sent: Montag, 16. Juni 2014 13:43
> > >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.
Agree to start with simple primitives first
Louay
Received on Monday, 16 June 2014 12:00:28 UTC