- From: Eric Uhrhane <ericu@chromium.org>
- Date: Wed, 29 Feb 2012 09:58:40 -0800
- To: Darin Fisher <darin@chromium.org>
- Cc: Kinuko Yasuda <kinuko@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Feb 28, 2012 at 1:52 PM, Darin Fisher <darin@chromium.org> wrote: > On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda <kinuko@chromium.org> wrote: >> >> Hi, >> >> While looking at the FileSystem API draft I noticed that we only expose >> 'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't >> have 'size' field unlike File object maybe it's reasonable to add 'size' >> field to Metadata? >> >> http://www.w3.org/TR/file-system-api/#the-metadata-interface >> >> Without adding this we can indirectly get the file size by creating 'File' >> object via FileEntry.file() method and accessing File.size, but when an app >> wants to display the modificationTime and file size at once (and it sounds >> very plausible use case) the app needs to call two different async methods-- >> which doesn't sound very nice. WDYT? >> >> Thanks, >> Kinuko >> >> > > > I think this is a nice improvement. File size is very obviously something > one might expect to be included in meta data for a file :-) > > -Darin Yup. I've had this recommended offline at Google as a way to speed up directory listings. Currently, for each Entry that you get from a DirectoryReader, you have to call getMetadata to get mtime, then getFile to get size. This cuts the number of calls in half, which can be a pretty big deal for a large directory. I'll put it in. Charles, I'd like to leave the may-be-nice ones out for now--it's easy to add them later, and the current design also makes it easy for implementers to add other fields experimentally. If others think that this rises to the same importance of size, we can certainly discuss it.
Received on Thursday, 1 March 2012 07:16:38 UTC