Re: [FileAPI] createObjectURL isReusable proposal

On 1.3.2012 4:38, Feras Moussa wrote:
> 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
>

Hi,
are we talking about
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
?
because I still do not see, what have you solved...
Ok, instead of mutable string, you have an object, fine
but when you create this URL object out of Blob and assign that URL to 
HTMLImageElement source, you are stuck again
1/ when will be such URL object be GC'd?
2/ when will underlying Blob be GC'd?
3/ what would @src of that image return? (or ancestor's innerHTML)?



Brona

Received on Thursday, 1 March 2012 07:07:46 UTC