Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 5:23 PM, Jian Li <jianli@chromium.org> wrote:
> The other alternative is to have both FileReader and BlobReader, while the
> former one is for reading only File object and the later one is for reading
> any Blob object. With that, we also have FileReaderSync and BlobReaderSync.

That seems like an excessive solution to the "you can read blobs with
FileReader even though 'blob' isn't in the name" problem.

/ Jonas

> On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov <dimich@chromium.org> wrote:
>> > As for wild ideas, it also could be something more generic, lets say
>> > DataReader which can take Blobs and Files (and perhaps something else in
>> > the
>> > future). Like XHR that has overloaded methods for xhr.open(..).
>> > It seems possible that web developers may not realize that File is
>> > actually
>> > a Blob and may be confused by using BlobReader to read File. ("Do I need
>> > to
>> > make a Blob out of my File first?"). They may be equally confused by
>> > using
>> > FileReader to read Blob though.
>>
>> That would address item 1 on my list. But not item 2 through 4.
>>
>> / Jonas
>>
>> > On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> >>
>> >> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher <darin@chromium.org>
>> >> wrote:
>> >> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking <jonas@sicking.cc>
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan <arun@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.
>> >>
>> >> I somewhat agree. But it seems equally strange to use BlobReader to
>> >> read files, and I suspect that it will be vastly more common to read
>> >> files than blobs-that-aren't-files.
>> >>
>> >> Yes, the File interface inherits Blob, so technically when you're
>> >> reading a file you're also reading a blob, but I doubt that is the
>> >> mental model most people will have.
>> >>
>> >> Like so many other things, there is no perfect solution here.
>> >>
>> >> > 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.
>> >>
>> >> I've been thinking about this too. I can't say I feel strongly either
>> >> way. It feels somewhat strange, but I can't come up with any solid
>> >> technical reasons against it.
>> >>
>> >> / Jonas
>> >
>> >
>
>

Received on Tuesday, 31 August 2010 00:26:27 UTC