Re: File API Feedback

On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan<arun@mozilla.com> wrote:
> Hixie, I think a Base64 representation of the file resource may be
> sufficient, particularly for the image use case (which is how it is used
> already).  Can you flesh out why the new schema is a good idea?

so. I have folders with 100-1000mb of pictures in them. If I decide
that I want to upload them all (Picasa style), i'd expect it would
take a very long time to convert each file name into a base64 url.

It sounds like part of the goal is to be able to retain references to
files across crashes.

As an example, I occasionally decide to upload the contents of
"stress" (about 1000 images and 100mb iirc). The url for stress can be
found in a bug report.

1. User visits "uploader page"
2. User selects the contents of an entire folder (stress) with a file picker
3. Browser provides relatively tiny urls which are opaque to the Web
App for each of the files
4. Web App stores the opaque urls into localstorage
5. Web App asks for the data for the first couple urls
6. Web App starts showing previews and uploading files
7. As files are uploaded, webapp removes opaque urls from localstorage
8. Web app repeats 5-7 w/ other files from 4
9. Browser crashes; web  app has uploaded say 100 items of my 1000 items
10. Browser restarts; web app is able to use localstorage and opaque
urls to continue uploading the remaining 900 items.

the requirements for such an opaque url are:
a. that the browser retain a mapping to the real file paths
b. that opaque urls the browser hasn't generated for a given web
application not be usable by that web application

one potential scheme:
browser-file-reference://host.principle.example.com:port/opaque-sequence-number

note that at this time, the web apps working group is trying to
propose a widget: scheme, and the amount of push back web apps is
getting from various groups is quite high. -- just something to keep
in mind.

Received on Friday, 19 June 2009 03:01:15 UTC