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

Hi MarkW, All,

On 28 May 2014, at 20:55, Mark Watson <watsonm@netflix.com> wrote:

> As far as I can see, the use-case I am concerned with is already well in-scope according to the current charter text.

Good to hear, then no changes needed to the charter. Although we should strive to make the scope as clear as possible so that we do not end up arguing mid-way what should be in the scope and what not. Better we use our time on productive work than arguing :-)

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

Ok.

> ​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?

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

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

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?

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

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

Thanks,

-Anssi

Received on Thursday, 29 May 2014 09:48:38 UTC