- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Thu, 19 Jun 2014 06:05:17 +0000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- CC: "Rottsches, Dominik" <dominik.rottsches@intel.com>, "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>
Hi Anssi, > -----Original Message----- > From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] > Sent: Mittwoch, 18. Juni 2014 08:56 > To: Bassbouss, Louay > Cc: Rottsches, Dominik; B.Lund@cablelabs.com; watsonm@netflix.com; > fd@w3.org; markdavidscott@google.com; mfoltz@google.com; > ddavis@w3.org; ph@w3.org; public-webscreens@w3.org > Subject: Re: Requesting display of non HTML content (was: Draft of Second > Screen Presentation Working Group Charter available) > > Hi Louay, All, > > On 16 Jun 2014, at 14:59, Bassbouss, Louay > <louay.bassbouss@fokus.fraunhofer.de> wrote: > > >> 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. > > [...] > > > Agree to start with simple primitives first. > > I also support this approach. It is aligned with the Extensible Web design > principles [1], and also my recent findings from the requestShowMedia.js > experiment [2,3] provide further supporting data points. Thx Anssi for the demo and from my site completely I agree to spec the simple primitives first :) > To recap, once we spec the simple primitives and browsers implement them > (often, the smaller the feature, the faster the adoption) we can, together > with the wider web developer community, build JavaScript libraries on top to > experiment and iterate on new ideas pre-standardization, and bring the best > of these ideas to the standards track. > > For example, the requestShowMedia.js is an experimental implementation > of the ideas discussed at [4]. > > Thanks, > > -Anssi > > [1] http://extensiblewebmanifesto.org/ > [2] https://github.com/webscreens/requestshowmedia > [3] http://webscreens.github.io/requestshowmedia/demo/ > [4] http://lists.w3.org/Archives/Public/public- > webscreens/2014May/0061.html Thx Louay
Received on Thursday, 19 June 2014 06:05:58 UTC