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

[File API] Recent Updates To Specification + Co-Editor

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 28 Jun 2010 14:20:39 -0700
Message-ID: <4C291227.8030905@mozilla.com>
To: Web Applications Working Group WG <public-webapps@w3.org>
CC: public-device-apis <public-device-apis@w3.org>
Greetings WebApps WG,

I have made edits to the File API specification [1].  There are a few 
things of note that I'd like to call the WG's attention to.

1. There is a name change in effect.  FileReader has been re-named 
BlobReader, upon request from Chrome team folks[2][3].  The name 
"BlobReader" won't win awards in a beauty pageant, but it tersely 
describes an object to read Blobs (which could originate from the 
underlying file system *or* be generated *within* a Web App).  My 
present understanding is that FileWriter will also undergo a name 
change.  Naming is really hard.  Firefox already ships with FileReader, 
but I see the point of having an object named for what it does, which in 
this case is certainly more than file reading from the underlying file 
system.  I also abhor bike shedding, especially over naming, but this is 
something that's exposed to the authors.  I have not renamed FileError 
or FileException.  In the case of errors and exceptions, I think *most* 
scenarios will occur as a result of issues with the underlying file 
system.  These names should remain.

2. I've updated the URL scheme for Blobs using an ABNF that calls for an 
"opaque string" which is a term I define in the specification.  There 
was much discussion about this aspect of the File API specification, and 
I think the existing scheme does allow for user agents to tack on origin 
information in the URL (this is not something the spec. says you should 
do).  The actual choice of opaque string is left to implementations, 
though the specification suggests UUID in its canonical form (and 
provides an ABNF for this).  I think this is the most any specification 
has said on the subject of URLs.

3. There is an additional asynchronous read method on BlobReader, and an 
additional synchronous read method on BlobReaderSync, namely 
readAsArrayBuffer.  These use the TypedArrays definition initially 
defined by the WebGL WG [4].

4. I am moving on from my full-time role at Mozilla to a part-time 
consulting role.  I'll continue to be an editor of the File API, but I 
am stepping down as Chair of the WebGL WG.  I'll continue to be active 
in standards communities, though :-)

5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor 
of the File API specification.  Most people who work on HTML5 and 
WebApps know Jonas' contributions to both WGs; with everyone's consent, 
I'd like to nominate him as co-editor.  His model for an asynchronous 
event-driven API is what prompted the initial rewrite, and he also works 
on both File API and IndexedDB implementation (amongst other things).

-- A*

[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
[4] 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Received on Monday, 28 June 2010 21:21:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT