Re: New FileAPI Draft | was Re: FileAPI feedback

I'd really like to contribute to this as I'm helping implement WebGL and we
need a way to get LOTS of data into WebGL. Hundreds of files per app.

That said, there's a bunch of things I don't understand about the API

*) Given that XMLHttpRequest is limited to a same domain policy but the img
tag, audio tag, video tag, script tag and others are not, how do you resolve
that with the FIle API?

In other words, I want I be able to use the File API to download images but
it's not so useful if it's more restrictive in getting those images than the
IMG tag is.

Conversely, I suspect no one wants the File API to be able to be used to get
around the XMLHttpRequest restrictions for text.

Suggestion:  Allow the File API to download files from anywhere but if the
file is not from the same domain only File.getAsURL works. Since the URL
returned would only be useful for other tags that take a URL (img, audio,
video, etc..) that solution would mean you could download images, video,
audio etc through the File API no matter where they come from but it would
still limit it for the text case which is the only case that XMLHttpRequest
is useful for.

*) I don't understand how the File object is supposed to know mime type if
it hasn't downloaded the file yet.

Am I missing something. File is from the FileList but nothing has been
loaded/downloaded yet until you call one of the inherited FileData.get???
functions.

*) Add support for gzipped tar files.

No one responded to my previous suggestion. I don't know if that was because
it was so far outside the scope of what people thought the File API was for
or if no one had time.

It's imperative that support for some compressed archive format be available
to standard JavaScript in the browser. The canvas tag, the audio tag, WebGL
and others being added to HTML5 mean that all the kinds of applications you
see made with Flash using hundreds of assets will need to be downloaded to
do the same things in HTML5. The only efficient way to get there is to
support a some kind of archive format.

*) Progress support.

If I'm using the File API to download some data I'd like to be able to
display a progress indicator if the data is large. Is there some way that
could be added?


An alternate suggestion: Change the API to be more like XMLHttpRequest so

var req = new FileRequest();
req.open("GET", url, true);
req.onfileready = myFileReadyCallback;
req.onreadystatechange = myProgressIndicatorCallback;
req.send();

// This function gets called periodically while downloading is
// happening. That way you can check progress
function myProgressIndicatorCallback() {
  document.getElementById('progress').innerHTML =
      req.bytesSoFar / req.length;
}

function myFileReadyCallback() {
  if (!req.error) {
     var fileObject = req.file;
     var text = fileObject.getAsText();  // if from same domain
     var dataURL = fileObject.getAsDataURL();  // if from same domain
     var filedataURL = fileObject.getAsURL();  // always valid since it's
opaque to JavaScript
  }
}

Then.  Change FileList so it's just a list of special URLs.  Either
filedata: urls or "localfile: <uuid>" or something to that effect. Therefore
JavaScript doesn't get to know the actual path of the file, the browser
handles that, but you still get access to both local files by use selection
and remote files by url easily and you still get progress reports from the
request. The process of downloading the data (the request) is now separate
from the process of using a file that has been downloaded.

Just an idea.