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

Hi MarkS, All,

On 28 May 2014, at 11:14, Mark Scott <markdavidscott@google.com> wrote:

> We agree on this principle - and I hope that this specific discussion on support for existing devices that can only play a limited set of content types doesn't detract from this.

I’m happy to hear we’re aligned on the fundamentals. I have a proposal how to resolve this below.

> You'll see this approach in what we've done to date with Chromecast - we'll render and send any web content to the device (using the one-UA model), but if there's a "custom player" available we'll use it when possible because it results in a better user experience.  I use YouTube and Netflix as examples, but this isn't about favoring large players.  Anyone can build one of these custom players for Chromecast at essentially no cost -but Roku similarly has thousands of channels, and Android-based devices like Fire TV support DIAL but allow any app to be installed (I think).  However, these relatively open devices still use "custom player" models, at least in part because pure HTML doesn't even define simple functions like how to adjust (master) volume.
> 
> Like you, I'm optimistic we'll find an appropriate technical solution; I feel it's close to what's already defined, and that we need some level of available screen filtering regardless even to handle speaker vs. picture frame vs. display.  I jumped into the thread mostly to express a view that it's important that we define APIs for the web that work well with as many screens as possible.

Do you think it would be reasonable for you to experiment with the alternative URL schemes via a separate proprietary API (spec this as an extension to the Presentation API) for the time being, and keep the core Presentation API well specified and limited to text/html?

My proposed resolution to this general issue is (please let me know if this does not work for you):

Let’s first specify and ship an API that does text/html extremely well in the proposed *Working Group*, and then, after we’re collectively confident we can do it, think about what comes next.

Your input and expertise will play a key role in defining “what comes next”. The right venue for that type of work is the *Community Group*, as defined in the WG charter (see “Dependencies” [1]).

I don’t want to block anyone from experimenting with cool new stuff on the Web platform, I just feel that we should not bring experiments to the standards track (that is, to a Working Group) until there's wide support.

Looking back, when the Community Group was chartered, we provided concrete input to it in a form of a draft spec and an experimental implementation. Since then, wider interest emerged and it was proposed [2] this work to be moved to a Working Group. That is what is now explicitly mentioned in the WG charter in the Deliverables. I feel it would be reasonable that proposals that go beyond that scope should follow a similar path: incubate in the CG, and move to the WG when the consensus emerges and we are confident we can get to multiple interoperable implementations.

Thanks,

-Anssi

[1] http://webscreens.github.io/charter/#coordination
[2] http://lists.w3.org/Archives/Public/public-webscreens/2014Apr/0011.html

Received on Wednesday, 28 May 2014 09:09:18 UTC