Adding gzipped archive support to XMLHttpRequest and the File API?

I hope I'm in the right place.

I'd like to propose / suggest that XMLHttpRequest be extended to handle
gzipped tar files. Usage would be something like

var req = new XMLHttpRequest();
req.onfileavailable = myOnFileAvailable;
req.open("GET", "http://someplace.com/somefile.tgz", true);
req.send();

// This function is called as files in the archive are downloaded.
// In other words, you do NOT have to wait for the entire archive
// to be downloaded. The archive is downloaded and decompressed
// asynchronously and as each file in the tar is completely download
// loaded this callback is called with a File object representing
// that file
function myOnFileAvailable(fileObject) {
  // fileObject is a File API type object. The data is available at this
point is
}

This extension is needed for rich web applications of the type that would
use
the canvas 2d or canvas 3d API to implement things like games or other apps
that require thousands of small to large assets.

In that vane I'd also like to suggest a new URL. (forgive me if there is
already a standard for this. Just point me in that direction)

File currently has getAsDataURI and getAsText. Unfortunately neither of
those are sufficient for the needs of the applications this proposal is
trying to deal with. getAsText clearly only handles text and getAsDataURI
has severe size restrictions.

How about added getAsBinaryURI something to this effect.

"binary:???" where "???" is some ID made up by the browser, guaranteed to be
unique within one HTML page. The data it represents is not available
directly to HTML but you can pass it to things that use URIs so for example.

img.src = file.getAsBinaryURI();
audio.src = file.getAsBinaryURI();

etc..

I'll be honest, I feel like there is certain mis-match between the File API
as current specified and the use cases that apps like I'm referring to need.

Given that in the example above when myOnFileAvailable is called the file is
completely available it would be cumbersome to have to add yet another
callback to have to use file.getAsBinaryURI in an asynchronous manner.  In
other words.  I'm hoping I wouldn't have to do this

// NOT THIS PLEASE

function myOnFileAvailable(fileObject) {
  fileObject.getFileAsBinaryURI(myFileAsBinaryURICallback);
}

myFileAsBinaryURICallback(binaryURI) {
  someImgElement.src = binaryURI;
}


Though maybe that's not so bad. It would get called immediately in this case
because the fileObject already has the data but would still allow it to be
used for files not in an archive as well.

Thoughts?