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

On Wed, May 28, 2014 at 9:22 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

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

​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