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.
