W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Updates to File API

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 2 Jun 2010 15:42:25 -0700
Message-ID: <AANLkTinp97t4UcMx7eQybDmZt-RgcDkeOh7IWIT7aeNl@mail.gmail.com>
To: arun@mozilla.com
Cc: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>

In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob.  Is
that just an oversight, or is that an intentional restriction?


On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> Greetings WebApps WG,
> I have updated the editor's draft of the File API to reflect changes that
> have been in discussion.
> http://dev.w3.org/2006/webapi/FileAPI
> Notably:
> 1. Blobs now allow further binary data operations by exposing an ArrayBuffer
> property that represents the Blob.  ArrayBuffers, and affiliated "Typed
> Array" views of data, are specified in a working draft as a part of the
> WebGL work [1].  This work has been proposed to ECMA's TC-39 WG as well.  We
> intend to implement some of this in the Firefox 4 timeframe, and have reason
> to believe other browsers will as well.  I have thus cited the work as a
> normative reference [1].  Eventually, we ought to consider further read
> operations given ArrayBuffers, but for now, I believe exposing Blobs in this
> way is sufficient.
> 2. url and type properties have been moved to to the underlying Blob
> interface.  Notably, the property is now called 'url' and not 'urn.'  Use
> cases for triggering 'save as' behavior with Content-Disposition have not
> been addressed[2], although I believe that with FileWriter and
> BlobBuilder[3] they may be addressed differently.  This change reflects
> lengthy discussion (e.g. start here[4])
> 3. The renaming of the property to 'url' also suggests that we should cease
> to consider an urn:uuid scheme.  I solicited implementer feedback about URLs
> vs. URNs in general.  There was a general preference to URLs[5], though this
> wasn't a strong preference.   Moreover, Mozilla's implementation currently
> uses moz-filedata: .  The current draft has an editor's note about the use
> of HTTP semantics, and origin issues in the context of shared workers.  This
> is work in progress; I have removed the section specifying urn:uuid and hope
> to have an update with a section covering the filedata: scheme (with
> filedata:uuid as a suggestion).  I welcome discussion about this.  I'll
> point out that we are coining a new scheme, which we originally sought to
> avoid :-)
> 4. I have changed event order; loadend now fires after an error event [6].
> -- A*
> [1]
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
> [2] http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
> [3] http://dev.w3.org/2009/dap/file-system/file-writer.html
> [4] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0910.html
> [5] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0462.html
> [6] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0062.html
Received on Wednesday, 2 June 2010 22:43:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:08 UTC