Re: Updates to FileAPI

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