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

Re: File API: Directories and System

From: Mike Clement <mikec@google.com>
Date: Mon, 12 Apr 2010 12:17:49 -0700
Message-ID: <j2j3ecc8b3f1004121217sa53b05b2r85da1d4482fccb92@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: public-device-apis@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:43 UTC