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<da...@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