Re: [FileAPI] createObjectURL isReusable proposal

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

Received on Tuesday, 14 February 2012 13:58:18 UTC