Re: HTML Media Capture draft from Device APIs and Policy Working Group

On Thursday, July 22, 2010, Dominique Hazael-Massieux <> wrote:
> (re-sending, sorry for the previous mis-sent)
> Le mercredi 21 juillet 2010 à 11:18 -0700, Jonas Sicking a écrit :
>> The MediaList interface is unnecessary. The Files returned from the
>> FileList interface can implement the MediaFile. Compare to how
>> NodeList interface always returns Node objects, but that those Node
>> objects often also implement Element or TextNode.
>> Why is MediaFile defined to only be implemented on Files captured
>> using a device? Why not also allow it to be implemented by files that
>> reside on the users file system?
> Good points, I've removed the MediaList interface and amended the text
> to read:
>         If the user selects files of whose MIME types match image/*,
>         sound/*, or video/* (on the filesystem or via a successful media
>         capture), the relevant files in the files attribute [HTML5] must
>         implement the MediaFile interface.

Sounds good!

>> It's probably a good idea to make the FormatData accessor
>> asynchronous. Otherwise implementations are required to read all such
>> data into memory every time a MediaFile is instantiated.
> So, you're suggesting an asynchronous MediaFile.getFormatData() rather
> than the MediaFile.format attribute? I can see the value of not loading
> up data into memory ever time, but this will make access to these data
> rather more painful for developers; that may be an acceptable price to
> pay.

Indeed. Asynch APIs are definitely more painful to use. However
authors usually also care about performance, so slow performing UAs
are also painful them.

/ Jonas

Received on Thursday, 22 July 2010 16:37:32 UTC