On Mon, 17 Aug 2009 20:12:50 -0400, Arun Ranganathan <a...@mozilla.com> wrote:

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

I have a more specific proposal about simulating HTTP status codes for file: operations that I'll be posting soon.

I also have an alternate proposal to post soon for a simple FileReader api to replace the local file loading part of DOM3 L&S, document.load and XHR.

I also have some questions about using the new FileAPI to load files on file:// without the use of <input type="file">.

(Will post these things in new threads soon.)

--
Michael

Reply via email to