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

Hi MarkW,

On 28 May 2014, at 18:02, Mark Watson <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.

“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 ;-)

> 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.

> 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.

> 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 16:26:08 UTC