- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 22 Jul 2010 09:30:10 -0700
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org WG" <public-html@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On Thursday, July 22, 2010, Dominique Hazael-Massieux <dom@w3.org> 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