- From: Robin Berjon <robin@robineko.com>
- Date: Tue, 13 Apr 2010 11:29:44 +0200
- To: Mike Clement <mikec@google.com>
- Cc: Eric Uhrhane <ericu@google.com>, public-device-apis@w3.org
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 http://robineko.com/
Received on Tuesday, 13 April 2010 09:30:15 UTC