W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: FileSystem API: Adding file size field to Metadata?

From: Eric Uhrhane <ericu@chromium.org>
Date: Wed, 29 Feb 2012 09:58:40 -0800
Message-ID: <CAHvSExfGxEmBdxkcVGVv=enpMOKB693LJW86iG2keJjnhygqQA@mail.gmail.com>
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
Received on Thursday, 1 March 2012 07:16:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC