Re: Survey ready on Media Multitrack API proposal

On Thu, 04 Mar 2010 11:45:43 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Thu, Mar 4, 2010 at 2:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>
>> On Mar 3, 2010, at 12:40 PM, Silvia Pfeiffer wrote:
>>
>>> On Thu, Mar 4, 2010 at 3:33 AM, Eric Carlson <eric.carlson@apple.com>
>>> wrote:
>>>>
>>>> On Mar 2, 2010, at 11:14 PM, Silvia Pfeiffer wrote:
>>>>
>>>>>>
>>>>>> You also didn't answer my second question -  are track names  
>>>>>> typically
>>>>>> unique? Do media container formats generally guarantee the presence  
>>>>>> of
>>>>>> unique track names?
>>>>>
>>>>> There is no guarantee of their existence - same for the role
>>>>> attribute. But where they exist, they are unique.
>>>>>
>>>>  Track IDs (which are numeric) in QuickTime and MPEG-4 files are
>>>> guaranteed to be unique, track names are not required and are *not*
>>>> guaranteed to be unique.
>>>
>>>
>>> So maybe for MPEG the track ID is the one that should be mapped to the
>>> this field here as text? Or alternatively it could be a combination of
>>> track name and the track ID?
>>
>> It seems like you can always provide a numeric indexing API to the  
>> tracks
>> regardless of the media format. How about we make that the primary way  
>> to
>> query for a track, and leave the name as an informative field?
>>
>> Using a numeric ID as a string name would be particularly confusing  
>> with the
>> proposed API, since there are both name and index getters. Let's say you
>> have a track that is first in the MediaTracks list, and it has a numeric
>> track ID of "2".
>>
>> You might expect that myVideoElement.tracks["2"] will get the track  
>> with ID
>> 2. But it will instead get the third track in the tracks list. That's
>> because index getters take priority over name getters, and
>>  myVideoElement.tracks[2] means the same thing as
>>  myVideoElement.tracks["2"] in JavaScript. For this reason, it is a bad  
>> idea
>> to provide both index getters and name getters when the names may be
>> numeric.
>>
>> I suggest that we drop the name getter, since the index getter is more
>> fundamental. No matter what kind of query you want to do, you can alway  
>> loop
>> over all the tracks using tracks.length and the tracks index getter.
>
> OK, I see the problem. I didn't consider that JavaScript converts sees
> no difference in [2] and ["2"].
>
> I have no issue with removing the getter on namedItem. I don't think
> it's important.
> The other getter already does the index by number.

I agree with removing it. The only reason it was there to begin with was  
because the HTMLCollection interface was copied. The remaining  
tracks.item(n) is not very useful as it is only a longer way of writing  
tracks[n]. Is it really necessary to keep it for these hypothetical  
non-ECMAScript languages that might implement the interface?

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 4 March 2010 05:09:31 UTC