- From: Mike Clement <mikec@google.com>
- Date: Mon, 12 Apr 2010 12:17:49 -0700
- To: Eric Uhrhane <ericu@google.com>
- Cc: public-device-apis@w3.org
- Message-ID: <j2j3ecc8b3f1004121217sa53b05b2r85da1d4482fccb92@mail.gmail.com>
Eric, I have a few questions/ideas/concerns: 1) I think there will be the need to provide multiple sandboxes per origin. For example, there are obviously many google.com web apps out there, but they all shouldn't share the same exact sandboxed filesystem. I propose adding something similar to how Shared Workers provides for an optional "name" parameter to distinguish between multiple contexts. That is, I'd like to see requestTemporaryFilesystem and requestPersistentFilesystem take an optional "name" parameter that can be used to create a wholly separate sandbox based on origin+name as a unique identifier. That way each web app can be assured it is only dealing with files that it created in the first place. So far, this is my only "dealbreaker" issue, since I can't imagine having to coordinate with all potential web app developers on a domain, nor would I gladly share quota with them all. 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). 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. 4) Might getCreationDate also be useful? I can't wait for this API to be come a reality! Regards, Mike Clement On Fri, Apr 9, 2010 at 6:45 PM, Eric Uhrhane <ericu@google.com> wrote: > I've put up a draft of the filesystem API [1] based on the sketch I > emailed out back in January [2]. It's a bit rough around the edges, > but I wanted to get it up there for comments without making everyone > wait any longer--no point in polishing it too much before it's set, > anyway. > > I look forward to your feedback. > > Eric Uhrhane > ericu@google.com > > [1] http://dev.w3.org/2009/dap/file-system/file-writer.html > [2] > http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0229.html > >
Received on Monday, 12 April 2010 19:18:22 UTC