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

Re: File API: Directories and System

From: Eric Uhrhane <ericu@google.com>
Date: Tue, 13 Apr 2010 16:31:55 -0700
Message-ID: <p2u44b058fe1004131631gb6512008i602a138d6aa491e2@mail.gmail.com>
To: Mike Clement <mikec@google.com>
Cc: public-device-apis@w3.org
On Mon, Apr 12, 2010 at 12:17 PM, Mike Clement <mikec@google.com> wrote:
> 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.

What if each product just decided to make its own top-level
subdirectory?  Then they could share if they wanted to.  Of course, it
would require that every Google product cooperate to some extent, or
at least have a coding standard, but that doesn't seem like a large
restriction for any smaller developer, and it keeps the interface from
growing.

> 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 carefully didn't specify what that number means.  I don't want to
put hard requirements on quota-handling; I think we need UAs to
experiment to come up with good UI and policies.  UAs are free to take
that number as a hint, give you a smaller amount of storage without
bugging the user, then prompt the user later on when you use a bunch
more than expected.  We've got a lot of client-side storage APIs now,
and they're all getting various amounts of disk quota.  I think UAs
need to come up with a unified quota management system, and putting
too many requirements in each storage API spec will only make things
harder.

> 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 am, but that's not unreasonable.  Anybody else have a strong preference?

> 4) Might getCreationDate also be useful?

It might, but I'd like to keep the API as small as possible and grow
it as needed.  If it's maybe-useful, but not vital, let's leave it out
until version 2.

> I can't wait for this API to be come a reality!

Thanks, and keep the questions+suggestions coming.

     Eric

> 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 Tuesday, 13 April 2010 23:32:46 UTC

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