- 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