Nikunj R. Mehta wrote:
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?
Currently, this behavior is not standard, and there are interoperability
issues across user agents. Michael Puls II did ran some tests some time
ago and posted these on this listserv:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0200.html
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?
Again, this isn't standard behavior, and Firefox doesn't provide these
headers over file://
Separately, I disagree with Anne about restrictions on XHR, but don't
wish to preempt that discussion till filedata: is better defined.
-- A*