Re: FileSystem API: Adding file size field to Metadata?
On Tue, Feb 28, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote: On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@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.
FileSystem API: Adding file size field to Metadata?
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
Re: FileSystem API: Adding file size field to Metadata?
On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@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
Re: FileSystem API: Adding file size field to Metadata?
On Feb 28, 2012, at 1:52 PM, Darin Fisher da...@chromium.org wrote: On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@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 :-) Content type may be nice as well. Whatever the OS reports. -Charles
