Re: File API "oneTimeOnly" is too poorly defined

On 29.3.2012 9:29, Darin Fisher wrote:
> I've never been terribly happy with createObjectURL and the 
> requirement for
> folks to remember to call revokeObjectURL.  I really like that we're 
> talking
> about ways to minimize this pain :-)
> I noticed the WeakRefs proposal:
> It also makes use of the micro-task concept, and it does so to avoid 
> revealing
> details about garbage collection.
> What if we were to adopt a similar approach here.  Instead of 
> introducing a
> second parameter to createObjectURL, what if createObjectURL returned a
> WeakObjectURL object instead of a String object?  WeakObjectURL could
> be converted to a String to reveal the Blob URL.
> Suppose WeakObjectURL if retained would keep the Blob URL valid.  Else,
> when WeakObjectURL gets deleted, its Blob URL would remain alive up
> until the next micro-task.
> Crazy idea?  Too crazy?
> I agree that it is valuable to define "dereference" points for APIs 
> that receive
> Blob URLs.
> -Darin
So the WeakObjectURL would exists as long as Blob exists?

//so this function will automatically GC Blob, URL object and the url 
string itself would be reference to 'nothing' (since blob does not 
exists anymore)?
function fileInputOnChange()
    var blob = this.files[0];
    var url = blob.getWeakObjectURL();
    document.getElementById('firstImage').src = url;

//so this function will not automatically GC Blob nor URL object and the 
url string will be still pointing to that Blob?
var blob  = MyGlobalFiles[0];
function loadBlob(blob)
    var url = blob.getWeakObjectURL();
    document.getElementById('firstImage').src = url;

//and when I remove any reference to that blob, all will be GC and 

that sounds interesting and probably like one of the best idea in this 
long discussion....


Received on Thursday, 29 March 2012 07:56:49 UTC