Re: Lifetime of Blob URL

As a developer who eagerly awaits this API, I'm fine with using File-
prefixes for most everything, since many times a "file" in many APIs is
really an abstraction for a stream of data anyway, and I think that most
experienced developers can wrap their heads around that.

That's my two cent's worth,
Mike


On Mon, Aug 30, 2010 at 5:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
> >> >
> >> >
> >
> >
>
>