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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 17 22:46:41 PDT 2011


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





--- Comment #5 from Eric Carlson <eric.carlson at apple.com>  2011-03-17 22:46:41 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > 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).
> 
I think keeping it behind a 'webkit' prefix is definitely a requirement until the spec is much more mature.

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

> What do you think?
> 
As I said, there is nothing like real implementation experience to help shape a new API, so I think this is a useful effort. As I also noted the spec is still very young and it will likely change after we have an implementation, but as long as we use a 'webkit' prefix and acknowledge that it is very likely we may have to break early adopters I don't have a problem with proceeding.

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



More information about the webkit-unassigned mailing list