Re: Lifetime of Blob URL

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:18:47 UTC