W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

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

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 22 Jul 2010 09:58:43 +0200
To: Jonas Sicking <jonas@sicking.cc>
Cc: Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org WG" <public-html@w3.org>, public-device-apis@w3.org
Message-ID: <1279785523.2282.1000.camel@localhost>
(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.

> 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

Received on Thursday, 22 July 2010 07:58:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:22 UTC