- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 10 Nov 2010 21:12:30 -0800
- 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