Re: File API: Directories and System

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.


>
> > 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?  :)


> > 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
> >>
> >
> >
>