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

Re: File API: Directories and System

From: Robin Berjon <robin@robineko.com>
Date: Tue, 13 Apr 2010 11:29:44 +0200
Cc: Eric Uhrhane <ericu@google.com>, public-device-apis@w3.org
Message-Id: <3E1FFAB8-EB18-43A9-885E-92A301FD65C5@robineko.com>
To: Mike Clement <mikec@google.com>
Hi Mike,

On Apr 12, 2010, at 21:17 , Mike Clement wrote:
> 2) Is it necessary for each call to requestTemporaryFilesystem/requestPersistentFilesystem to specify the expected size, even if the filesystem already exists?  For example, if the filesystem already exists, shouldn't I be allowed to pass 0 as the size parameter to get the current filesystem?  What happens if the requested size passed in is smaller than the current size of the filesystem?  Should it evict files, or just return the larger filesystem intact?  I guess what I'm getting at is that quota management will eventually become a bigger issue here and it would be nice to include some sort of guidance if not some functionality here (e.g., a callback to the web app informing it that quota has been exceeded and that files are being evicted, maybe giving it the opportunity to ask for more space).

I have similar concerns. I think that in many cases developers will have very little idea of how much space they might end up consuming  in a lot of situations it depends entirely on what the user does and is therefore completely outside of their control. What this is likely to lead to is some sort of magic number that has been shown to work for all implementations which developers will just use without any further thought.

I think that we might simply remove this constraint and leave it up to UAs to figure out how to handle quotas. Failing that, it would be good to find some form of workable precedent.

> 3) getFile/getDirectory are a bit overloaded.  How about including methods like exists(), createFile() and createDirectory()?  Though these methods are easily implemented in terms of getFile/getDirectory, I always prefer more direct API methods that help make the code easier to understand.  I expect, though, that you are attempting to be a low level as possible here.

I agree that it might be worth adding createFile() and createDirectory(), both with a boolean to represent the EXCLUSIVE flag. I'm not against exists() per se but we have to keep in mind that this is an async API that may be implemented atop a networked FS such as TAHOE. Testing for existence then creating means that you have two round-trips to the server and callbacks nested two levels deep for something as simple as create it if it doesn't exist. That's suboptimal.

> 4) Might getCreationDate also be useful?

As I said previously, if we start having several metadata fields I'd rather we had a single getMetadata() call (again, this means a single trip to the server  it's like caching the results from stat()).

Robin Berjon
  robineko  hired gun, higher standards
Received on Tuesday, 13 April 2010 09:30:15 UTC

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