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<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
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
