On 14.2.2012 14:39, Charles Pritchard wrote:
On 2/14/2012 5:35 AM, Bronislav Klučka wrote:


On 14.2.2012 5:56, Jonas Sicking wrote:
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson<i...@hixie.ch>  wrote:
On Thu, 2 Feb 2012, Arun Ranganathan wrote:
2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful
in mitigating some of our fears. Hixie, is this possible?
Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too (e.g.
what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, would
it still have the image?).
We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas


The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating...

What do you think of a global release mechanism? Such as URL.revokeAllObjectUrls();

Sounds like very interesting idea... could clearly solve a lot of issues here (load everything you want on load and the release it once) . So +1

But I would still leave some functionality for one image manipulation, there still can be apps with mixed approach (some images with reusable {application data}, some images without {application UI}), ore they may not be even images here (images one time, but some file blob permanent). I could also go with reverse approach, with createObjectURL being oneTimeOnly by default
createObjectURL(Blob aBlob, boolean? isPermanent)
instead of current
createObjectURL(Blob aBlob, boolean? isOneTime)
the fact, that user would have to explicitly specify, that such URL is permanent should limit cases of "I forgot to release something somewhere"... and I thing could be easier to understant, that explicit request for pemranent = explicit release. Would break current implementations, sure, but if we are considering changes....

B.



Reply via email to