W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

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

From: Eric Uhrhane <ericu@google.com>
Date: Mon, 28 Jun 2010 14:44:28 -0700
Message-ID: <AANLkTilYjsZhsrJ6FFkCfysatmdVp7oMZG_2upbBuLE0@mail.gmail.com>
To: arun@mozilla.com
Cc: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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.

I've just made the corresponding changes to FileWriter [->BlobWriter]
in both the FileWriter and FileSystem specs.  I've not changed the URL
of the FileWriter spec, though, for simplicity.

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

Sounds good.  Thanks Jonas!

> -- 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:45:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:08 UTC