Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 8:47, Ian Hickson wrote:
> On Sat, 28 Jan 2012, Kyle Huey wrote:
>> On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher<darin@chromium.org>  wrote:
>>> I'm not sure what a concrete proposal would look like.  Maybe
>>> Element.URL.createObjectURL or just Element.createObjectURL?
>> Wouldn't returning an object (which can be GCd) be a better solution?
> The whole point of the API is that we have an object but need a string (a URL).
>
Hi,
current pain here is that we have an string that can reference object 
and we have no idea when to release such object automatically (before 
document onunload). I do not know  how to make my following suggestion 
in specification speech, but how about that
use caching and regular URL-like approach:
how would I implement it being browser developer:
1/ requiring of string identifier of Blob would make this blob part of 
caching mechanism, I would create temporary directory accessible by this 
document only and store blob data there e.g. under a file name abcd-efgh 
and return abcd-efgh as a blob URL (or use other mechanism that would 
allow direct conversion between string to file name).
2/ variable representing original blob could be subjected to regular GC, 
because I already have data copy to that URL, and those are not in 
memory (Or I could leave those data in memory for some time if assume I 
would need them soon (pseudo code):  x = blob.url; <some code>; img.src 
= x;)
3/ any call requiring some blob url would be to resolved in application 
memory (if such blob exists there) or simply by checking application 
cache (it does not matter where do I get the URL, it can always be 
converted to one particular file name)
4/ on document unload, the cache would be cleared (to prevent problems 
with browser crash, I would probably create those temp directories based 
on document URL and clear the cache, every time such document is opened 
in it's first instance (if such cache would exists from previous time))

This user agent behavior may go beyond the scope of HTML specification, 
but we already have Offline web application cache...

We could always leave the revokeObjectUrl call to simply delete content 
from cache...

Brona

Received on Friday, 3 February 2012 06:36:20 UTC