Re: [FileAPI] BlobBuilder.getBlob should clear the BlobBuilder

On Wed, Apr 13, 2011 at 2:46 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Another advantage of dropping the memory automatically is that you
> don't need to copy any data into the Blob. Instead you can just make
> the Blob take ownership of whatever memory buffers you've built up
> during the various calls to .append. You could technically implement
> some sort of copy-on-write scheme, but that introduces complexity.
>

You don't actually need copy-on-write for that, so long as Blobs are
immutable.  You only need to refcount the underlying chunks comprising the
Blob, so the chunks can be shared between Blobs.

I think a complete, mature Blob implementation would be fairly complex,
anyway.  For example, in order to support very large blobs, Blob and
BlobBuilder might scratch to disk transparently.  (This wouldn't happen
during BlobBuilder.append, since that's synchronous.  Rather, it would
happen when other async APIs create Blobs, pushing the amount of memory used
by blobs over some threshold; that way the swapping of blobs to disk could
be done asynchronously.)

Since it appears Blob is becoming a major API building block for storing
larger blocks of data, I don't think this is unreasonable complexity to
expect in the longer term.

> The problem is that this optimizes for the rare case when you're
> creating several blobs which are prefixes of each other.

The above having been said, it's not necessary for BlobBuilder to keep its
data around in order to satisfy the uncommon "blobs which are prefixes of
each other" case.  You can do the following:

  var bb = new BlobBuilder();
  bb.append(lots_of_data);
  var blob1 = bb.getBlobAndReset(); // does what it says
  bb.append(blob1);
  bb.append(some more_data);
  var blob2 = bb.getBlobAndReset(); // returns lots_of_data + some_more_data

This could be optimized by the browser as above: the second, larger blob
could share data with the first.

-- 
Glenn Maynard