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