On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or
otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each File
object is
just a URL in the format
"filedata: uuid, filename"
Then you can use that URL anywhere in HTML a URL is valid. script,
img,
audio, video, css, AND XHR
That would mean you wouldn't be adding a new API to get the
contents of a
file. If you want the contents just use XHR and use the URL from
the File in
the FileList.
You could add a few more functions to XHR like
request.getAsDataURL(),
request.getAsTextInEncodiing(), etc. if need be if they are neede
Today, it's possible to use XHR from "privileged web content" in
Firefox to access file:// URLs; the drawback is that these don't
return HTTP responses, and of course there are security
considerations.
As stated, the XHR algorithm for open() [1] allows relative references
and resolves them relative to the document base URI. Does that mean
that if the document was loaded using file: uri, then the XHR could be
used for loading a file?
As a separate question, it would be necessary for proper operation of
XHR to always provide content-type and content-length headers when
providing a response entity body. Does Firefox provide these headers
when the XHR object is used to retrieve local file: representations?
I'm not sure it is necessary to reuse the XHR primitive for general
file access (though I find the idea of not distinguishing remote
files from local pretty attractive), but I have defined the
filedata: URL scheme to return some HTTP response codes [1], so that
it can be used with XHR. What is permitted and what is not is bound
to be a controversial discussion :-)
-- A*
[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Nikunj
http://o-micron.blogspot.com
[1] http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest
