Re: [FileAPI] createObjectURL isReusable proposal

On 24.2.2012 20:49, Arun Ranganathan wrote:
>> On 24.2.2012 20:12, Arun Ranganathan wrote:
>>> Bronislav,
>>>
>>>
>>>> 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....
>>> So, having these URLs be "oneTimeOnly" by default itself has
>>> issues, as Glenn (and Darin) point out:
>>>
>>> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html
>>>
>>> The existing model makes that scenario false by default, trading
>>> off anything "racy" against culling strings.
>> We are back in an issue of someone using oneTimeOnly or permanent in
>> an
>> inappropriate case.  Programmers should be aware of what they are
>> doing.
>> I actually have no problem with current specification (rermanent as
>> default, expicit release), I'm just trying to prevent changes like
>> assigning object to string attribute (e.g. src), returning innerHTML
>> with empty string attribute (e.g. src)
>
> My solution is that src should be modified to take both a string and a URL object, which makes innerHTML behavior easier; I'm less sure of it taking Blob directly.
>
> -- A*
What change would it make compared to current scenario? URL as string or 
URL as stringifiable object? What's the difference?


B.

Received on Friday, 24 February 2012 21:10:11 UTC