Re: Draft of Second Screen Presentation Working Group Charter available (was: Heads-Up: Plan for Working Group on Second Screen Presentation)

On Fri, May 30, 2014 at 1:26 AM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

>  Hi MarkW,
>
>
>
> How do you imagine the usage of your API proposal to play this video
> http://example.com/video.mp4 on for example a UPnP MediaRenderer?
>

​My proposal does not address that use-case.​



> what is the value of the input parameter in presentation.requestScreens(…)?
>

​With this information, the UA can filter out screens that could not render
that URL. For example, if the URL is www.netflix.com and the UA detects a
device using DIAL that does not have the Netflix app, the presence of that
device alone would not trigger the onavailabilitychange event.​ Of course
if there is another device with the Netflix app, or if there is a second
screen connected via MirraCast etc., that can render any URL, then the
event would fire.

...Mark



>
>
> Regards,
>
> Louay
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Donnerstag, 29. Mai 2014 20:52
> *To:* Kostiainen, Anssi
> *Cc:* public-webscreens@w3.org; Mark Scott; Rottsches, Dominik; mark a.
> foltz; Bob Lund; Bassbouss, Louay; 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 Anssi,
>
>
>
> On Thu, May 29, 2014 at 2:48 AM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
>
> Hi MarkW, All,
>
>
> On 28 May 2014, at 20:55, Mark Watson <watsonm@netflix.com> wrote:
>
>
> > ​That just seems very restrictive. You're not abstracting anything away
> if there is no scope for diversity in the UA implementations.​ If a UA is
> capable of interacting with other kinds of remote display - whilst keeping
> the Presentation API clean and independent of the type of remote display -
> I think that should be allowed.
>
> Can you clarify what concretely should be allowed?
>
>
>
> ​It should be allowed to request the rendering of URLs that, when rendered
> by a remote app, are interpreted directly in some application-specific way,
> rather than as a locator for an HTML document to be rendered.​
>
>
>
>
> I argue the following out of scope for the Presentation API to be worked
> on in the WG:
>
> requestFoo(‘random://foobar/baz');
>
> (... and I want to make this explicit in the charter after we’ve settled
> on the issue.)
>
>
>
> ​It's not clear to me yet that the use-case of a remote service-specific
> app can be fully addressed with only http URLs. But it's also not clear
> that it can't.
>
>
>
> For my part, I had been assuming that http URLs would be sufficient. But
> since custom URI schemes have been suggested, I'm not sure we should rule
> them out yet.
>
>
>
> It's also not clear to me how such schemes could be ruled out *in a
> charter*: they are very much a specific technical solution, not a
> requirement or use-case.​
>
>
>
> However, see below ...
>
>
>
>
> While this would be allowed:
>
> requestFoo(‘http://www.example.org/foobar/baz');
>
> To be clear, when the implementation performs an HTTP fetch using '
> http://www.example.org/foobar/baz' URL:
>
> GET /foobar/baz HTTP/1.1
> Host: www.example.org
>
> These are the response headers (along with other headers, but the
> text/html is the relevant bit here) followed by the HTML payload:
>
> HTTP/1.1 200 OK
> Content-Type: text/html; charset=utf-8
>
>
>
> ​I think what you are saying is that you would like the Presentation API
> to al​ways assume that the given URL can be rendered by a HTML5-compliant
> UA (just as a UA makes this assumption about a URL put into the URL bar).
> So, if the UA supports the model where it renders the content locally,
> off-screen, and transmits it over some wireless display technology
> (essentially as a video stream), then this will always be able to work.
> [Or, equally, the case where the second screen UA is itself remote].
>
>
>
> We could design the API with this assumption, but in practice there are
> going to URLs that don't work in the above cases. Whether a given site can
> work in this model depends a lot on the capabilities of the UA doing the
> rendering and potentially on the display connection technology as well. For
> a video site, for example, it may require technologies such as EME, MSE,
> WebCrypto, H.264 which may not be universally supported. If a site is using
> EME, then whether the video can be displayed also depends on the properties
> of the link to the display (such as whether it supports HDCP).
>
>
>
> Furthermore, whether the remote display works in this model also relies on
> the site author providing support for it, which is a business decision for
> them as to whether to invest resources in that case.
>
>
>
> So, it would be nice for the case that the site author knows this will not
> work, for the failure to be graceful (for example for the user not to be
> offered these screens to choose from).
>
>
>
> Anyway, this is a detail we can look at in the working group. My point is
> mainly that if there are *n *different second screen scenarios, even if
> the API is uniform across then, you can't in a specification force site
> authors to support them all, both for compatibility reasons and just
> because site authors have a choice about which to support.
>
>
>
>
> Then, for a proposal how to address the "web media types such as images,
> audio, video, or application-specific media” part of the following:
>
> [[
>
> The web content may comprise HTML documents, web media types such as
> images, audio, video, or application-specific media, depending on the
> capabilities of the secondary display for rendering the media.
>
> ]]
>
> ...  please see my reply to Francois’ and respond in that thread:
>
>   http://lists.w3.org/Archives/Public/public-webscreens/2014May/0061.html
>
> > > Furthermore, I don't think it's a good idea to leave out a class of
> screens now to be "bolted on" later. The user experience for the different
> kinds of second screen should be identical: users and developers do not
> care whether they are using MirraCast, AirPlay, Cast etc. they just want to
> know which screens they can "fling" to. Based on the list discussion, the
> requirements for this use-case are very simple: up-front provision of the
> URL by the site so that UAs can appropriately filter displays.
>
> Is the proposal discussed in my reply to Francois’ compatible with your
> thinking around this?
>
>
>
> ​My concern is mainly with the service-specific apps case which I see as
> orthogonal to the arbitrary content-type case addressed in that proposal.​
>
>
>
>
> > This would make a great Community Group work item, that we should bring
> to the standards track when we have more experience and concrete proposals
> on the table.
> >
> > > Just to be clear, what I imagine in the Netflix case is that the URL
> is one that would load our HTML5 player if sent to a remote HTML5 UA. But a
> controller UA that supports DIAL and its integration with Presentation API
> would also offer the user the choice of any devices it discovers that have
> the Netflix app. The protocol that the controlling site uses over
> postMessage might even be the same in both cases, although that is our
> problem. [For "Netflix" here also substitute any of the 100ish-and-growing
> DIAL apps [3].]
>
> Does my proposal fit with this model?
>
>
>
> ​It's orthogonal - see below.
>
> ​
>
>
> > I’d be interested in better understanding the approach described above.
> Could you provide us the simplest possible examples (preferably with
> [pseudo-]code and/or markup) how you envision the "HTML5 UA" and the
> "controller UA” to interact with the Presentation API?
> >
> > I’m hopeful we can find a way to make this work with the Presentation
> API, but we’d need more concrete input.
> >
> > ​I'll happily provide a proposed modification to the API to address the
> requirement as I see it. It's very simple. Is the right proposal to comment
> against is the one here:
> http://www.w3.org/community/webscreens/wiki/API_Discussion ? I think the
> email input I've provided in response to the call for comments on that
> proposal has been quite concrete, given the simplicity of the necessary
> change.
>
> Just show me the code how a web developer would be using the API to
> address your use case. You can base your proposal on top of any API, or
> spin your own if you feel like it.
>
>
>
> ​Ok, here is an off-the-top-of-my-head modification to the WebIDL from the
> Wiki - example code below.​
>
>
>
>
>
>   ​interface NavigatorPresentation {
>
>   ​  PresentationScreens requestScreens(optional DOMString url = "");
>
>   ​};​
>
>
>
> partial interface Navigator {
>
>   readonly attribute
>
>   NavigatorPresentation
>
>   ​ presentation;
>
> };
>
>
>
> interface PresentationScreens : EventTarget {
>
>    PresentationSession requestSession(DOMString url);
>
>    attribute EventHandler onavailablechange;
>
>    attribute EventHandler onpresent;
>
> };
>
>
>
> // No changes below here...
>
>
>
> [Constructor(DOMString type, optional AvailableChangeEventInit eventInitDict)]
>
> interface AvailableChangeEvent : Event {
>
>   readonly attribute boolean available;
>
> };
>
>
>
> dictionary AvailableChangeEventInit : EventInit {
>
>   boolean available;
>
> };
>
> [Constructor(DOMString type, optional PresentEventInit eventInitDict)]
>
> interface PresentEvent : Event {
>
>   readonly attribute PresentationSession session;
>
> };
>
>
>
> dictionary PresentEventInit : EventInit {
>
>   PresentationSession session;
>
> };
>
> enum PresentationSessionState { "connected", "disconnected" /*, "resumed" */ };
>
>
>
> interface PresentationSession : EventTarget {
>
>   readonly attribute PresentationSessionState state;
>
>   void postMessage(DOMString message);
>
>   void close();
>
>   attribute EventHandler onmessage;
>
>   attribute EventHandler onstatechange;
>
> };
>
>
>
> ​Example:
>
>
>
>
>
> <button disabled>Show</button>
>
>
>
> *var* presentation = navigator.presentation,
>
>     showButton = document.querySelector('button')
>
>
>
> ​,
>
>
>
>
>
>  ​   my​screens = presentation.requestScreens( 'http://www.netflix.com' );
>
>
>
> my​screens.onavailablechange = *function*(e) {
>
>   showButton.disabled = !e.available;
>
>   showButton.onclick = show;
>
> };
>
>
>
> *function* show() {
>
>   *var* session = my​screens.requestSession('http://www.netflix.com/WiPlayer?movieid=70248289
>
>
>
> ​
>
>  ');
>
>
>
>   session.onstatechange = *function*() {
>
>     *switch* (session.state) {
>
>       *case* 'connected':
>
>         session.postMessage(*/*...*/*);
>
>         session.onmessage = *function*() { */*...*/* };
>
>         *break*;
>
>       *case* 'disconnected':
>
>         console.log('Disconnected.');
>
>         *break*;
>
>     }
>
>   };
>
>   }​
>
>
>
> ​In this example, the user would be offered second screens detected by
> DIAL that have the Netflix app as well as second screens which support a
> general-purpose UA. The URL ​
> http://www.netflix.com/WiPlayer?movieid=70248289
>
> ​ is one that will play the content item in a regular UA, if it has the
> necessary capabilities (in the case of this URL that means Silverlight).
> What I mean in my point above is that we could instead provide a URL
>
> http://www.netflix.com/unsupportedScreen.html so that the remote app case
> would work but the general UA case might not. We could discuss making that
> failure mode better for the user, such as a way not to list those screens
> at all.
>
>
>
> ...Mark
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
> -Anssi
>
>
>