Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:34, Bronislav Klučka wrote:
>
>
> 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
>

BTW. I know It sounds a lot like something that can be done with 
FileSystem API, but I hope the ease and benefits for developers are 
clear here, FileSystem API would be overkill for this (and easier to 
implement for vendors without FileSystem API implemented yet)

Brona

Received on Friday, 3 February 2012 06:40:25 UTC