[Webkit-unassigned] [Bug 56459] Implement the HTML5 Media Streaming API

Thu Mar 17 17:31:58 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=56459

--- Comment #4 from Andrei Popescu <andreip at google.com>  2011-03-17 17:31:58 PST ---
Hi Eric!

Many thanks for the comments!

(In reply to comment #3)
> (In reply to comment #2)
> > Sure, I understand it's a moving target as we have closely followed the relevant standards mailing 
> > lists. At the same time, Chromium is very interested in implementing and maintaining this spec 
> > and we're fully committed to keeping the WebKit code as close to the standard as possible.
> > 
> > I was wondering if you had any advice about this: do you feel it's premature to add this API to WebKit? 
> > Or would you be ok with us adding it already now and committing to keeping it up to date?
> > 
>   While I agree that this is an important feature, and I definitely think that there is nothing like real implementation experience to make sure an API does everything it should, I am concerned that shipping a feature before an API settles can have a bad effect on both the web and on WebKit's ability to implement the final spec. 
>

Totally agreed. It is not in our intention to ship this API before it is ready but rather get the implementation experience you mentioned and provide feedback to the standardisation effort. We were thinking of keeping this API behind a 'webkit' prefix (and in Chromium, it would also be behind a runtime flag).

>   We implemented and shipped <video> very early, but the element had been in the spec for more than six months and there had very extensive debate on the mailing list. We shipped it knowing that we *would* break existing content if the spec changed, and it indeed it has changed significantly several times since we shipped our first implementation - and we updated and broke existing content when it did. 
> 
>   Are you willing to commit to breaking early adopters when the spec changes? It will change.
> 

Yep, it will definitely change. However, there have been precedents of APIs that WebKit implemented despite the standard being a moving target (e.g. IdexedDB). In these cases, using the 'webkit' prefix for the API method names made it clear to the early adopters that the API may change quite dramatically.

>   Because this is a JavaScript-only API at this point, wouldn't it be possible to implement this in an application and inject the JavaScript API into WebKit at runtime?

The API is meant to interact with existing elements such as <video> or APIs, while it's methods are meant to return types such as Blob. I am therefore not sure how feasible it would be to implement it as you suggest. Rather, I feel it would be more beneficial to try and implement it properly in WebKit, provide feedback to the standard and iterate.

What do you think?

All the best,
Andrei

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.