- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Fri, 24 Feb 2012 22:09:47 +0100
- CC: public-webapps@w3.org
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