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

Hi MarkW,

Thank you for the additional explanations and follow-up. It’s good to have this engaging open discussion. I’ll try to make the thread a bit more concise and summarise, please correct me if you feel the core ideas are incorrectly summarised:

1) You’d like the information about whether screens are available be specific to an URL scheme or a content type to match specific player apps on the second screen side.

2) You suggest to interface with a wider set of remote players/devices, not only those that would be a user agent rendering web content and those that would understand to playback a video stream that the initial UA sends them? For example, a YouTube.com<http://YouTube.com> or a Netflix specific player app that receives a content identifier of some sort. And you suggest to enable a custom type of communication to such players.

However, I don’t see any new solutions to the content-type specific negotiation issues that I explained before. It’s a risk to the success of the specification that we as a group try to produce if in our first iterations developers are left alone with sorting out such compatibility trouble. The developer would figure out what content formats to provide and what protocol to speak, instead of a simple API that allows to use familiar web content authoring and communication methods.

Also, I have not seen a device that would only have such custom player apps, but would not support a protocol or method to send it a pre-rendered video stream of web-content, or render such web content itself and could support web-messaging like communication. If you feel there is a large share of such devices and we can come to an agreement in the group that we want to support these, please let us know which devices you have in mind.

NSD provides raw access to the discovery protocols alone. As I mentioned, it seems unlikely to gain wide traction because of the security and privacy issues. We need something much higher level like the Presentation API.

The use cases for NSD describe not only the discovery, but also communicating with the advertised services, once they are found. Exactly what you seem to be looking for, from:
https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#use-cases-and-requirements

• Web pages should be able to communicate with Local-networked Services using the messaging channel supported by those Devices.

• Web pages should be able to communicate with Local-networked Services using the messaging format supported by those Devices.

I would strongly agree with you that we need something higher level, and I am convinced, this would also be more developer friendly and simple. We should avoid overlap to the scope of NSD, for its known privacy and security concerns.

I’d like us to focus on the core idea of the community group: Bringing web content to nearby secondary screen, by asking what is the minimum spec and what are the minimum technical requirements we would need to enable that?

We digress from this focus if we try to enable any type of communication, to any player software for enabling any custom content that such players may support, which I find similar to your suggestion 2). NSD is the way to do that, and it would certainly work well in a SysApps context, but as far as we can see from the discussion on blink-dev maybe not as an API that’s exposed on the open web.

To summarize, presupposing I interpreted your points 1+2 correctly, what is proposed seems to be out of scope for the Working Group.

That said, that is definitely something interested parties should continue experiment in this Community Group, and bring to the standards track when the ideas are more thought out.

Regards,

Dominik

Received on Monday, 26 May 2014 12:38:34 UTC