RE: [FileAPI] createObjectURL isReusable proposal

We think the new property bag (objectURLOptions) semantics in the latest 
editors draft are very reasonable. We have an implementation of this and 
from our experience have found it very widely used internally with app 
developers - many leverage it as a way to get an easy to use one-time-use 
URL and avoid leaks in their applications. We've also noticed many 
developers easily overlook the URL.revokeObjectURL API, thus failing to 
realize they are pinning the resource behind the blob and further validating 
the usefulness of this.
 
To address a few of the implementation questions that were raised in 
this thread:
> Something else that needs to be defined: does "xhr.open('GET', url)" 
> consume the URL, or does that only happen when xhr.send() is called?
We think a URL does not get consumed until the data has been accessed. As 
XHR does not begin accessing the data until send has been called, we expect 
Blob URLs to be no different. The URL should get revoked  after xhr.send() 
gets called. This is also what we've done in our implementation, and have not 
noticed any confusion from developers.
 
>Another case: whether loading a one-shot URL from a different origin, 
>where you aren't allowed to load the content, still causes the URL to 
>be revoked.  (My first impression was that it shouldn't affect it at 
>all, but my second impression is that in practice that error mode would 
>probably always result in the URL never being revoked and ending up 
>leaked, so it's probably best to free it anyway.)
Similar to the above case, the URL is not revoked until after the data is 
accessed. If a URL is used from a different site of origin, the download fails 
and the data is not accessed, thus the URL is not revoked. Developers can 
notice this condition from the onerror handler for an img tag, where they 
can revoke the URL if it did not resolve correctly.
 
> What do you think of a global release mechanism? Such as 
> URL.revokeAllObjectUrls();
This wouldn't solve any of the problems previously listed in this thread, 
and would only be useful as a convenience API. That said, I'd question 
the trade-off of adding another API versus a developer writing their 
own version of this, which should be fairly trivial.
 
We also think the spec should clarify what the expected behavior is for 
a revoked URL when accounting for the image cache. The concept of 
revoking URLs is to give the developer a way to say they are done with 
the object. If a user agent still has the bits in memory, it should not be 
in the business of blocking the URL from loading, even if it is revoked.
 
We’d like to see the spec updated to clarify the points listed above 
and I'd be happy to help with these changes in any way possible.
 
Thanks,
Feras

> -----Original Message-----
> From: Bronislav Klučka [mailto:Bronislav.Klucka@bauglir.com]
> Sent: Friday, February 24, 2012 1:10 PM
> To: public-webapps@w3.org
> Cc: public-webapps@w3.org
> Subject: 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.h

> >>> tml
> >>>
> >>> 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 Thursday, 1 March 2012 03:40:07 UTC