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

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? what is the value of the input parameter in presentation.requestScreens(…)?

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<mailto:anssi.kostiainen@intel.com>> wrote:
Hi MarkW, All,

On 28 May 2014, at 20:55, Mark Watson <watsonm@netflix.com<mailto: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<http://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