On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan <a...@mozilla.com> > wrote: > >> In addition, BlobError and BlobException sound better because these > names > >> are consistent with current "Blob" naming scheme in File API. So we're > also > >> going to adopt these new names in the WebKit implementation when we > rename > >> FileReader to BlobReader per the spec. > > > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > > proliferation of Blob in the API [1] including other major implementors > (my > > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > > objections. I suppose you folks are pretty adamant on the Blob* name? > > I feel pretty strongly that we should name this back to FileReader, > for several reasons: > > 1. Most people that I talk to dislike the name Blob, much less having > it spread to things like BlobReader. > 2. My understanding is that the writer counterpart is going to be > called FileWriter (is this correct?) > Yes, that is what we are currently implementing in WebKit. > 3. While it's certainly possible to read Blobs with this, it seems to > me like the far most common case will be to read a "real" file, or > part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader > > It just seems odd to use an interface named FileReader to read blobs, which may not correspond to files. Consider BlobBuilder, which can be used to construct a Blob from a string. Another idea (possibly a crazy one) would be to eliminate Blob, and just use File for everything. We could rename BlobBuilder to FileBuilder and have it return a File instead of a Blob. Same goes for Blob.slice(). Of course, the File would not necessarily correspond to a real physical file on disk for performance reasons. -Darin