Re: Updates to FileAPI

Arun:

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.
>
> 2. Metadata attributes creationDate and lastModifiedDate have been added to
> the File object, per discussion on the WHATWG listserv.

My apologies for not bringing this up earlier; I just realized that
the discussions I've been involved with weren't on the public lists,
and I didn't share their conclusions on the relevant threads.

The creationDate is going to be problematic.  It works fine on
Windows, but not on Unix-style systems.

On Unix, ctime is *not* creation time.  It's the last time the inode
was modified, so e.g. changing permission bits will alter it.
http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime.

I see that your spec allows for an empty string on systems where
creationDate isn't available, but my gut response is not to add a
Windows-specific feature.

> 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'll update my specs to use unsigned long long where appropriate as well.
I'll also be updating my extensions to FileError/FileException.  Shall
I leave a gap, or just start numbering where you left off?

> 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 18:13:11 UTC