W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2010

Re: Updates to FileAPI

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 10 Nov 2010 21:12:30 -0800
Message-ID: <AANLkTinyqPZ9drBEp4F8YXRZw5j2y=pQfi69sZL6mCVB@mail.gmail.com>
To: Jian Li <jianli@chromium.org>
Cc: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, public-device-apis <public-device-apis@w3.org>
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 05:13:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:24 UTC