Updates to FileAPI

  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.

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.

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 Tuesday, 12 October 2010 17:47:42 UTC