Re: Updates to File API

Hi, Arun,

I have one question regarding the scheme for Blob.url. The latest spec says
that "The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:". Since the URL is now part of the Blob and it could be used
to refer to both file data blob and binary data blob, should we consider
making the scheme as "blobdata:" for better generalization? In addition,
we're thinking it will probably be a good practice to encode the security
origin in the blob URL scheme, like blobdata:
http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make
doing the security origin check easier when a page tries to access the blob
url that is created in another process, under multi-process architecture.

Indeed, the URL scheme seems to be more sort of implementation details.
Different browser vendors can choose the appropriate scheme, like Mozilla
ships with moz-filedata. How do you think?

Jian


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
>
>