W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2010

Re: Updates to FileAPI

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 14 Oct 2010 19:47:33 -0700
Message-ID: <AANLkTi=cO0iYTiQ7ev7eQuWx0-pK4gvK8pFFpSGZ3wNS@mail.gmail.com>
To: arun@mozilla.com
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, public-device-apis <public-device-apis@w3.org>, Kinuko Yasuda <kinuko@chromium.org>
On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan <arun@mozilla.com> wrote:

>  WebApps WG,
> There have been some updates to the File API.
> http://dev.w3.org/2006/webapi/FileAPI/
> Notable changes are:
> 1. Exception codes are no longer harnessed to DOMException's exception
> codes, per discussion on this listserv.
> I've updated the exception codes in the FileWriter and FileSystem specs to
match, and extended appropriately.  Now that we're not tied to the
DOMException codes, I was able to add codes that had been requested for some
very file-system-specific errors.

2. Metadata attributes creationDate and lastModifiedDate have been added to
> the File object, per discussion on the WHATWG listserv.
> 3. Blob no longer has a .url attribute.  Instead, Window and
> WorkerGlobalScope have been extended with methods createBlobURL and
> revokeBlobURL, per discussion on this listserv.
> 4. The Blob URI section has undergone changes, per discussion on this
> listserv.  Notably, Blob supports the addition of an HTTP Content-Type,
> which implementations must return as a response header when Blob URIs are
> dereferenced.
> 5. There are (ongoing) fixes to bugs, including incorrect uses of long long
> (in lieu of unsigned long long), per (ongoing) discussion on the listserv.
> I've updated the FileWriter and FileSystem specs to use unsigned long long
where appropriate as well.  Thanks for pointing that out.

In off-list discussion, a few points have come up, which I'll summarize
> below:
> 1. The emerging "HTML5 Device" specification [1] includes a section on
> streams and an affiliated Stream API, which relies normatively on Blob URIs
> [2] defined in the File API.  Since we've eliminated the .url property on
> Blob, we should also eliminate the .url property on the Stream object.
>  There has been some discussion on renaming the methods createBlobURL and
> revokeBlobURL to be more generic, so that use cases such as Stream can be
> accommodated.  This is an ongoing discussion.  In general, there's consensus
> around eliminating the .url attribute from Stream.
> 2. There is ongoing discussion about the addition of Content-Disposition as
> well (as an attribute on Blob, as a parameter to Blob.slice, and as a
> response header when dereferencing blob: URIs), to facilitate and optimize
> downloads.  The use of a Content-Disposition header allows URLs (both
> http:// and blob:) to dereference content straight for download, with the
> benefit of header-determined processing (e.g. the download doesn't occur
> first).  Another suggestion to address this use case is that instead of
> supporting Content-Disposition, to allow for an additional URL property on
> the FileSaver constructor, modulo domain restrictions.  This discussion is
> ongoing.
> 3. In general, there's ongoing discussion on allowing *even more* HTTP
> response behavior when dereferencing blob: URIs.  I strongly favor a strict
> subset of HTTP, and only a use-case driven addition of further response
> headers and response codes.  Arguments cited in favor of including all of
> http:// are that blob: URIs should be completely indistinguishable from
> HTTP URIs, thus allowing maximum reuse with XHR and other aspects of the
> platform.  Currently, I believe we allow for a great deal of intermingling
> without reproducing HTTP in its entirety within Blob URIs.
> -- A*
> [1] http://dev.w3.org/html5/html-device/
> [2] http://dev.w3.org/html5/html-device/#stream-api
Received on Friday, 15 October 2010 02:48:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:23 UTC