W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: New FileAPI Draft | was Re: FileAPI feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 12 Aug 2009 07:29:33 -0700
Message-ID: <4A82D1CD.8060601@mozilla.com>
To: Gregg Tavares <gman@google.com>
CC: Dmitry Titov <dimich@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
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.

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
Received on Wednesday, 12 August 2009 14:36:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC