W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 12 Apr 2011 21:32:19 -0700
Message-ID: <4DA52753.3040807@helsinki.fi>
To: Eric Uhrhane <ericu@google.com>
CC: Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>
On 04/12/2011 05:33 PM, Eric Uhrhane wrote:
> 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.
I agree. getBlob() sounds very much like read-only operation.
If there is a use case for clearing BlobBuilder, the method
should be called takeBlob() or some such.


> 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 04:32:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC