- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 28 Jun 2010 14:44:28 -0700
- 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:15 UTC