Re: Systematic access to media/plugin metadata

On Wed, 13 Apr 2011 16:34:49 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Wed, 2011-04-13 at 14:15 +0200, Philip Jägenstedt wrote:
>> Something like <http://www.w3.org/TR/mediaont-api-1.0/> might be a
>> better
>> approach, even though I don't think that API is suitable for
>> implementation in browsers as-is.
>
> The spec says "The API is implemented in a user agent (e.g., browser or
> browser plugin) and exposed as a JavaScript API (using the WebIDL
> JavaScript binding)."
>
> Yet, the API spec is silent on basic stuff required of browser API
> design such as saying what happens if getProperty is called on a media
> element whose external media resource hasn't been loaded yet. This and
> your assessment that the API isn't suitable for implementation in
> browsers make me wonder if there are there any browser vendors who are
> planning to implement this API and are carefully reviewing it for
> suitability for implementation in browsers. (It seems like a bad idea to
> spec an API for a class of products if there isn't interest in
> implementation and review among vendors of the class of products.)
>
> Are there browser vendors planning to implement this API?
>

I actually read through most of it a year or so ago and evaluated it.  
There are lots of little things that are a bit atypical for Web API's,  
like having a separate interface for pretty much everything: FrameSize,  
Language, Copyright, etc. There's a single global namespace for  
interfaces, so exposing these seems like a bad idea.

However, the biggest problem is that it provides a unified view of all  
tracks of a media resource, instead of per-track as we'd really want to  
have it. There is a NumTracks interface, but that doesn't seem to solve  
the problem.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 20 April 2011 09:08:52 UTC