Re: Updates to FileAPI

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