- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 12 Apr 2011 17:33:05 -0700
- To: Kyle Huey <me@kylehuey.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Apr 12, 2011 at 3:38 PM, Kyle Huey <me@kylehuey.com> wrote:
> Hello All,
>
> In the current FileAPI Writer spec a BlobBuilder can be used to build a
> series of blobs like so:
>
> var bb = BlobBuilder();
> bb.append("foo");
> var foo = bb.getBlob();
> bb.append("bar");
> var bar = bb.getBlob();
> foo.size; // == 3
> bar.size; // == 6
>
> My concern with this pattern is that it seems that one of the primary use
> cases is to keep a BlobBuilder around for a while to build up a blob over
> time. A BlobBuilder left around could potentially entrain large amounts of
> memory. I propose that BlobBuilder.getBlob() "clears" the BlobBuilder,
> returning it to an empty state. The current behavior also doesn't seem
> terribly useful to me (though I'm happy to be convinced otherwise) and be
> easily replicated on top of the proposed behavior (immediately reappending
> the Blob that was just retrieved.)
>
> Thoughts/comments?
>
> - Kyle
If you don't have a use for a current behavior, you can always just
drop the BlobBuilder as soon as you're done with it, and it'll get
collected. I think that's simpler and more intuitive than having it
clear itself, which is a surprise in an operation that looks
read-only. In the other case, where you actually want the append
behavior, it's faster and simpler not to have to re-append a blob
you've just pulled out of it.
Eric
Received on Wednesday, 13 April 2011 00:33:45 UTC