Hey Anssi,
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.
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.
Mark.
On Wed, May 28, 2014 at 12:17 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:
> Hi MarkS, All,
>
> On 28 May 2014, at 03:27, Mark Scott <markdavidscott@google.com> wrote:
>
> > I think we should talk concretely about what's actually being asked from
> an API perspective.
>
> What we are defining here is a Web API, that is, by definition, an API
> that works with the web content in the wild, and not just with vendor X's
> site.
>
> It is indeed easier to develop a solution if you control all the aspects:
> the site, the media it embeds, the way how this media is encoded, the
> browser. However, that is not how the Web works. The Web is about diversity
> and choice.
>
> The API must work for Netflix and Google but at the same time must not
> discriminate the small shops or independent developers. Similarly to any
> other Web API on the Web platform.
>
> The way how I see this is that the HTML is the lowest common denominator.
>
> If you can come up with a technical solution to the problems discussed in
> this thread that do work for the Web at large I’m more than happy to
> discuss them in this group and see if we can reach consensus required to
> extend the scope of the proposed WG charter.
>
> I’m sensing we’re getting closer to that already.
>
> Dominik will provide technical feedback so that we can keep the dialogue
> going, address these issues, and get to work. This reply was more about
> broad strokes.
>
> Thanks,
>
> -Anssi