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

Alternative File API

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 Aug 2009 19:20:12 -0700
Message-ID: <63df84f0908111920p79a55b03lbfbeb859469e785b@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
Here is an alternative proposal for an API for reading files:

[Constructor, Implements=EventTarget]
interface FileRequest {
  readAsBinaryString(in FileData filedata);
  readAsText(in FileData filedata, [Optional] in DOMString);
  readAsDataURL(in File file);


  const unsigned short INITIAL = 0;
  const unsigned short LOADING = 1;
  const unsigned short DONE = 2;
  readonly attribute unsigned short readyState;

  readonly attribute DOMString response;
  readonly attribute unsigned long status;

  attribute Function onloadstart;
  attribute Function onprogress;
  attribute Function onload;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onloadend;

Additionally, inside DOM Workers we could supply the following interface:

interface FileRequestSync {
  DOMString readAsBinaryString(in FileData filedata);
  DOMString readAsText(in FileData filedata, [Optional] in DOMString);
  DOMString readAsDataURL(in File file);

As stated, I'm not convinced that this is a better solution than what
the spec currently does. The only advantage I can see is that it
supports progress events without requiring the use of XMLHttpRequest,
and the downside is that it's a significantly bigger API. Usage
examples would be:

Current draft:
function handler(data, error) {

Above API:
reader = new FileReader;
reader.onload = handler;
function handler(event) {

I'd be interested in feedback from others, especially from people that
so far hasn't spoken up.

/ Jonas
Received on Wednesday, 12 August 2009 02:21:12 UTC

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