- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 10 Jan 2011 15:14:49 -0800
- To: "Gregg Tavares (wrk)" <gman@google.com>
- Cc: Charles Pritchard <chuck@jumis.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Fri, Dec 17, 2010 at 5:03 PM, Gregg Tavares (wrk) <gman@google.com> wrote: > > > On Fri, Dec 17, 2010 at 4:16 PM, Charles Pritchard <chuck@jumis.com> wrote: >> >> We're actively developing such functionality. >> >> The limit per directory is for the sake of the os file system. If you want >> to create a data store, use indexedDB or use standard file system practices >> (create a subdirectory tree). > > I think you're missing the point. If I have a folder with 6000 files on some > server and I want to mirror that through the FileAPI to the user's local > machine I'm screwed. I can't **mirror** it if it's not a mirror. > >> >> Disk space availability (quota) is an issue no matter what happens. When >> downloading 1000 images, you'll still only be doing so x at a time. > > I don't see the point you're trying to make here. I don't know the size of > the images before hand. Many internet APIs make getting the sizes > prohibitively expensive. One REST call per file. So before I can download a > single file I'd have to issue 1000 REST XHRs to find the sizes of the files > (waiting the several minutes for that to complete) before I can ask the user > for the space needed. That's not a good user experience. If on the other > hand the user can give me permission for unlimited space then I can just > start downloading the files without having to find out their ultimate size. > I suppose I can just request 1 terabyte up front. Or query how much space is > free and ask for all of it. I think that in this particular case, you'd want a better server API. "Hey, I want to download this whole directory. How much space will I need?". I realize that that's not always an option, but it's an alternative to what I just posted elsewhere in this thread: let the UA come up with a better quota system+UI. >> This issues are inherent in the design of any application of scale. At >> this point, the file system API does work for the use case you're >> describing. >> >> It'd be nice to see Blob storage better integrated with Web Storage Apis. >> Ian has already spoken to this, but no followers yet (afaik). >> >> -Charles >> >> >> >> On Dec 17, 2010, at 3:34 PM, "Gregg Tavares (wrk)" <gman@google.com> >> wrote: >> >> > Sorry if this has been covered before. >> > >> > I've been wanting to write an app to download images from photo sites >> > and I'm wondering if this use case has been considered for the FileAPI wrt >> > Directories and System. >> > >> > If I understand the current spec it seems like their are some possible >> > issues. >> > >> > #1) The spec says there is a 5000 file limit or directory. >> > >> > #2) The spec requires an app to specify how much storage it needs >> > >> > I understand the desire for the limits. What about an app being able to >> > request unlimited storage and unlimited files? The UA can decide how to >> > present something to the user to grant permission if they want. >> > >> > Arguments against leaving it as is: >> > >> > The 5000 file limit seems arbitrary. Any app that hits that limit will >> > probably require serious re-engineering to work around it. It will not only >> > have to some how describe a mapping between files on a server that may not >> > have that limit, it also has the issue the user might have something >> > organized that way and will require the user to re-organize. I realize that >> > 5000 is a large number. I'm sure the author of csh though 1700 entires in a >> > glob was a reasonable limit as well. We all know how well that turned out >> > :-( It's easy to imagine a video editing app that edits and composites >> > still images. If there are a few layers and 1 image per layer it could >> > easily add up to more than 5000 files in a single folder. >> > >> > The size limit also has issues. For many apps the size limit will be no >> > problem but for others.... Example: You make ray tracing program, it traces >> > each frame and saves the files to disc. When it runs out of room, what is >> > its options? (1) fail. (2) request a file system of a larger size. The >> > problem is (2) will require user input. Imagine you start your render before >> > you leave work expecting it to finish by the time you get in only to find >> > that 2 hours after you left the UA popped up a confirmation "this app >> > requests more space" >> > >> > The same would be true for an image downloading app. You start the app >> > to download a 1000 images, not knowing their sizes before hand. You start it >> > and leave. Half way through the UA puts up a conformation asking for more >> > space. >> > >> > Have these use cases already come up and been rejected? >> > >> > >> > > >
Received on Monday, 10 January 2011 23:15:34 UTC