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: Wed, 14 Apr 2010 20:49:29 -0700
Message-ID: <r2i44b058fe1004142049w2e1edc45n3a3d51f4444fe65b@mail.gmail.com>
To: Mike Clement <mikec@google.com>
Cc: public-device-apis@w3.org
On Wed, Apr 14, 2010 at 1:31 PM, Mike Clement <mikec@google.com> wrote:
> On Tue, Apr 13, 2010 at 4:31 PM, Eric Uhrhane <ericu@google.com> wrote:
>> 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.
> I suppose I see it as a scalability issue--where it can become more
> difficult/complex to use this feature as your site grows without some sort
> of control over granularity for both the developer and the user agent.
>  Imagine that your site makes heavy use of the filesystem for a lot of
> heterogeneous media types managed by a number of different web apps (e.g.,
> mysite.com/documentapp, mysite.com/musicapp and mysite.com/videoapp).  Now
> imagine you run out of space and need to delete a filesystem--similar to the
> way you can delete a local storage database.  If there is only one global
> filesystem for mysite.com, your only option is to delete all of the data for
> all of the mysite.com apps...but if each app had a named filesystem, then
> the user (or the user agent) could make more granular choices.  I might
> easily decide to give up my cached music for a while so that I can get more
> pictures.  For example, I can easily imagine a quota management dashboard UI
> where you might be allowed to prioritize filesystems and which ones get
> evicted before others where having the ability to have finer grained "silos"
> would be beneficial.
> I actually advocate shrinking the interface a bit.  Instead of
> requestTemporaryFilesystem and requestPersistentFilesystem, how about
> something like:
> requestFilesystem(boolean persistent, long long size, FilesystemCallback
> successCallback, optional ErrorCallback errorCallback, optional DOMString
> name);
> Anyway, just a thought.

We certainly do want to leave room for easy usage-management tools.
I'm not sure whether it's better/cleaner to put the name in now, or to
leave it out and see what folks want to experiment with.  I'll think
about it; more input welcome.

>> > 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'm beginning to like the getMetadata idea more, since it could be easily
> expanded by vendors by returning additional name-value pairs without waiting
> around for approval of a version 2+ spec.  If you can anticipate a need in a
> version 1 release, why not include it?  :)

That's a very good idea.  OK, I'm sold; getMetadata it is, and it'll
return an object with key/value pairs in it.

>> > 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 Thursday, 15 April 2010 03:50:15 UTC

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