[Bug 23479] File Constructor and Blob Constructor should have same signature

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23479

--- Comment #5 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Jonas Sicking from comment #3)
> "after GC" is key here. GC doesn't always collect all garbage. So for
> something like
> 
> var tempBlob = new Blob(...);
> var file = new File(tempBlob, "name");
> tempBlob = null;
> 
> the 'tempBlob' might get GCed after the 'file', hence retaining the data
> longer than needed.

This is an optimization, so the usual question applies: is this an actual
problem?  If the data is taking so many resources that it matters if it's held
a little longer, then it's a problem regardless of this, and the author needs
to be using .close().

(In reply to Jonas Sicking from comment #4)
> There is of course also the problem of what happens if someone forgets to
> null out the tempBlob variable in the code above?
> 
> Put it another way: Requiring the creation of temporary objects that retain
> large amounts of data is a bad idea.

Blob is fundamentally designed around making large temporaries (eg. slice(128)
to remove a header), so whack-a-moling a single case isn't a great idea. 
(Anyway, as long as tempBlob is local, it'll go out of scope at the same time
file does.)

I do think there's a simpler issue of the API being consistent; it's just a bit
weird to have to create a temporary Blob here, and for some properties to be
created when you create the File and some to be created when you create the
Blob.  Something like this *might* make sense:

[Constructor(sequence<(ArrayBuffer or ArrayBufferView or Blob or DOMString)>
blobParts, optional BlobPropertyBag options)],
Constructor(Blob fileBits, [EnsureUTF16] DOMString fileName)
]
interface File : Blob { }

To serve two different cases: creating a File from scratch, which you can now
do in the same way you create a Blob; and taking a Blob and making a File out
of it, which you can do the way it's specced today.

This feels messy, though, and like it would get messier as new Blob and File
subclasses are added (eg. ZipFile).  This needs more thought...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 11 October 2013 17:14:25 UTC