- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 14 Apr 2010 20:49:29 -0700
- 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