Re: Updates to FileAPI

Jian Li is right.  I'm fixing this in the editor's draft.

----- Original Message -----
> Good point; folks are going to want more precision than the day.
> 
> On Wed, Nov 10, 2010 at 9:03 PM, Jian Li <jianli@chromium.org> wrote:
> > I have a question regarding lastModifiedDate. The spec says that
> > this
> > property returns "an HTML5 valid date string". Per HTML 5 spec, a
> > valid date
> > string consists of only year, month and day information. It does not
> > contain
> > any time information. Do we really want this or what we want to
> > return is "a
> > local date and time string" per the HTML5 spec?
> > Thanks,
> > Jian
> >
> >
> > On Wed, Oct 13, 2010 at 4: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.
> >>
> >> 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 Thursday, 11 November 2010 07:44:01 UTC