Re: Draft of Second Screen Presentation Working Group Charter available

Hi all,

Apologies for top-posting. I have been following this discussion for a 
while now and I'm a bit confused, so here is an attempt to reformulate 
the problem at hand with my own words. Hope I got things right :)

I see two issues here. I agree with MarkW that both of them are already 
in scope for a potential working group given the current charter and 
that they should remain in scope. The short summary of that email is 
thus "no proposed change to the current draft charter".


Filtering out non compatible displays
-----
MarkW would like the browser to filter out connected displays that it 
knows to be incompatible with the URL that will be rendered. For 
instance, if the only connected display that the browser finds is a 
Netflix-only media player, and if the web application wants to issue a 
simple command such as:

   navigator.presentation.requestShow('http://example.org/index.html');

... the browser knows that this is not going to work. It would be better 
if the web application could first issue a call such as:

 
navigator.presentation.isScreenAvailableFor('http://example.org/index.html');

... that would return false (or a Promise that resolves to false) and 
decides to disable the "fling button" accordingly. The return value 
would be true in this example if a web application called:

   navigator.presentation.isScreenAvailableFor('http://netflix.com/foo');

... provided the web browser supports communicating with a Netflix media 
player and knows that it can render that content.

While not in the draft API so far, this is already covered from a draft 
charter perspective, and thus in scope of the possible working group to 
be (privacy concerns may or may not get in the way in the end, but 
that's a typical outcome of working group discussions).


Requesting display of non HTML content
-----
The second issue at stake is about specifying what happens when a call 
such as the following is issued:

   navigator.presentation.requestShow('video.mp4');

The main problem is that, regardless of where this runs, this does not 
create a "browsing context" as such since a video is not an HTML document.

While it's easy to see how a browser could create a fake browsing 
context for the video (as is done in practice when you open a link to a 
video in your browser), it's hard to see how the initiating page can 
communicate with the created browsing context to control video playback.

Here, my understanding is that Anssi and Dominik wants to put support 
for non HTML content out of scope of the working group, whereas MarkF, 
MarkS and MarW would like to leave it in. Is that a fair summary?

If support for non HTML content is in scope, the API needs to specify 
what happens in such a case. Main question is thus: how to control the 
media player from the initiating web application when you don't know 
anything about it? For media content, typical commands include: play, 
pause, seek, but what about subtitles?, switching to another format? 
etc. The commands could perhaps be borrowed from the HTML5 video 
interface. The Google Cast Chrome Media API could be a good starting point:

 
https://developers.google.com/cast/docs/reference/chrome/chrome.cast.media.Media

MarkS, MarkF, any input on this?

Now, if support for non HTML content is out of scope, the web 
application would have to issue a call such as:

 
navigator.presentation.requestShow('http://example.org/mediaplayer?url=video.mp4');

(or send the 'video.mp4' parameter in a message once the connection is 
established).

In other words, the web application would request display of a media 
player and give it the video to play as parameter, instead of requesting 
display of the video itself. This is typically what will happen for e.g. 
Youtube videos (since one never manipulates the URL of the actual video 
stream directly).

One problem I see with that approach is that, as a web application 
developer, I think I would often just want to play a video, and I'm not 
fond of having to provide the media player each time, as in "the content 
I want to present is the video itself, not the video in a page". I don't 
see how you can prevent people from doing that: the simplicity of the 
API just calls for such a usage.

More importantly, I can see browsers still supporting this use case, 
somehow. Here, the risk is that they will do things differently and thus 
expose different command messages to control the video from the web 
application. It might be hard to fix that in a second iteration of the 
API... unless the API includes some guidance or some sort of extension 
mechanism that allows people to experiment.

For instance, the API could say that, when given non HTML content, 
browsers need to render the necessary media controls chrome on top of 
the web application as if the video was playing locally. The web 
application would not be able to control the video in any way (apart 
from closing the show, that is) but the user would still be in control 
of the video, at least.

Another approach would be to say that what matters here is not the 
content type of the web content to display but rather the "control 
protocol" (for lack of a better word, in other words the command 
messages that the web application will send over the created 
communication channel) that the web application expects to use to 
control the content. When the URL to render is not an HTML content, the 
web application could perhaps specify in a second parameter to 
requestShow the control protocol that it intends to use. That second 
parameter could be a namespace, a URL or something else that describes 
the supported interface, as in:

   navigator.presentation.requestShow('video.mp4', 
'http://example.org/mediaplayer');

Here, the call would mean: "I request that the given video be shown on 
any secondary display that can play the video provided it supports the 
'http://example.org/mediaplayer' control protocol". The group may not 
specify any of these control protocols, the point being that people are 
free to experiment with and advertise different control protocols for 
different media types without breaking anything.

Regardless of the actual solution that ends up in the Presentation API, 
I do not think that the spec can remain silent as to what happens when a 
web application requests display of non HTML content.

As mentioned by MarkW below, the current charter has non HTML content in 
scope for the group: "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". So, here again, no change to the current wording.

Hope that helps,
Francois.


On 2014-05-28 19:55, Mark Watson wrote:
>
>
>
> On Wed, May 28, 2014 at 9:22 AM, Kostiainen, Anssi
> <anssi.kostiainen@intel.com <mailto:anssi.kostiainen@intel.com>> wrote:
>
>     Hi MarkW,
>
>     On 28 May 2014, at 18:02, Mark Watson <watsonm@netflix.com
>     <mailto:watsonm@netflix.com>> wrote:
>
>      > HI Anssi,
>      >
>      > Firstly, regarding the Community Group process, I raised the
>     use-case under discussion here on February 7 [1] and on February 10
>     you seemed to agree with the use-case [2]. Since then we have been
>     discussing details such as whether the UA shows the "flinging" icon
>     or whether the site shows that icon etc. So it is something of a
>     surprise to hear that you think the whole use-case (flinging to a
>     second screen using an service-specific app on that screen) should
>     be out-of-scope: we've been discussing it for months.
>
>     My comment was made in the context of the Community Group that
>     predates the Working Group chartering discussions. In this thread we
>     are discussing the scope for the proposed Working Group.
>
>     The scopes for these two groups differ from each other. The scope of
>     the WG is a subset of the CG scope and incorporates work that is
>     ready to advance to the standards track.
>
>     As you probably know, good charters accompany concrete input
>     document(s) per each deliverable to ensure the work that ends up in
>     the charter has better probability to be able to advance through the
>     standards track. Also beneficial is to have some implementation
>     experience before moving a deliverable into a WG. It is not a wish list.
>
>     More experimental work remains in scope for the Community Group, a
>     group type that is specifically designed for that.
>
>     If you want to propose changes to the WG charter scope, please
>     provide concrete text or send a pull request.
>
>
> ​As far as I can see, the use-case I am concerned with is already well
> in-scope according to the current charter text.
>
> Specifically, the API will allow a web site to "request display of web
> content on a connected display" and "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.". Furthermore, "The user
> agent is responsible for determining which secondary displays are
> compatible with the content that is requested to be shown through the API."​
>
> ​It seems clear to me that asking an app on a remote screen to render
> the content specific to that app is covered by the above.
>
> The suggestion that the URL be made available for filtering the results
> of discovery seems necessary for to make the last part above work.​
>
> ​Am I reading this wrong ? ​If you can explain what part of the draft
> charter you think excludes the use-case I will create a pull request for
> the group to consider.
>
>
>     “Flinging” is in scope for the Working Group AFAICT. Please clarify
>     what “flinging” means to you so that we can clarify this aspect in
>     the proposed Charter, and align ourselves. We do not call this
>     flinging in the Charter. Pull requests welcome ;-)
>
>
> I just mean the basic idea of having some content visible on your screen
> and having an icon which can send that same content to a remote screen.​
> And I include within this the case where the content is, say, a YouTube
> video and the remote screen has a YouTube app (and the local UA supports
> the necessary protocols to discover and make a connection with that app,
> be that DIAL, Cast or some combination).
>
>
>      > Secondly, regarding interoperability, there are two axes to
>     consider: UAs may support many different protocols for discovery and
>     sending to second screens: HDMI, MirraCast, WiDi, AirPlay, Cast,
>     DIAL etc. etc. For each of these there is an interoperability
>     question, but that is a question for those individual protocols.
>
>     Correct, these lower-level protocols are implementation details not
>     exposed through the Presentation API, as explained in the "External
>     Groups” section of the proposed WG charter:
>
>     http://webscreens.github.io/charter/#external-groups
>
>      > We do not expect every UA to support the entire list I gave above.
>
>     Correct. If your laptop only has a VGA output, you cannot plug it
>     into a display that has an HDMI input only. The API cannot change that.
>
>      > The interoperability problem that is relevant to our API is
>     whether a site using the Presentation API can work equally well on
>     one UA as on another *for the case that a second screen supported by
>     the UA is available*. Specifically, if a site works with UA1 for
>     flinging to an AirPlay receiver, but cannot fling to that same
>     receiver from UA2 because UA2 does not support AirPlay, that is not
>     an interopeability problem of the Presentation API. So, I do not
>     think consideration of additional types of second screen affects
>     interoperability: indeed our challenge is to design an API which
>     abstracts any differences between second screens and leaves it to
>     the UA implementation to present a simple and consistent API to web
>     developers.
>
>     This is why we use HTML as the lowest common denominator.
>
>
> ​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.
>
>
>      > 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.
>
>     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].]
>
>     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.
>
> There is almost no difference in terms of the code that uses the API
> from the present examples.
>
> ...Mark
>
>
>      > Finally, I think we should all be clear that the draft charter
>     [4] is just that, draft. It doesn't have any status yet. We're
>     discussing now what should be in or out of scope. If the current
>     draft suggests something be out of scope, but we agree on this list
>     to bring it in, we'll just change that draft.
>
>     Well, I hope people do understand what a draft means, that is why I
>     made it DRAFT and highlighted in yellow :-)
>
>     Thanks,
>
>     -Anssi
>
>

Received on Wednesday, 28 May 2014 21:35:34 UTC