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

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

From: Jian Li <jianli@chromium.org>
Date: Thu, 1 Jul 2010 18:31:55 -0700
Message-ID: <AANLkTim-E7QXYJOD1uu2iKf6pRRoPUgUxGBAiX-j_ABw@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>
One more question. Should we also rename FileError to BlobError and
FileException to BlobException in order to be consistent with the naming



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.
> 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 Friday, 2 July 2010 01:32:27 UTC

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