Re: [FileAPI] createObjectURL isReusable proposal

> 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*

Received on Friday, 24 February 2012 19:49:53 UTC