Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/2011 5:10 PM, Ian Hickson wrote:
> On Wed, 14 Dec 2011, Jonas Sicking wrote:
>> On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson<ian@hixie.ch>  wrote:
>>> On Wed, 14 Dec 2011, Glenn Maynard wrote:
>>>> The problem isn't the cost of the URL mapping, it's the cost of
>>>> keeping the backing Blob around.  If you drag around Google Maps for
>>>> a long time, and it used object URLs to load its tile images, it'd be
>>>> very bad if the browser had to keep every tile graphic around for the
>>>> lifetime of the page.
>>> Browsers do keep them around for the lifetime of the page, in their
>>> HTTP cache.
>> This isn't true at least for Firefox. We allow resources to be kicked
>> out of the HTTP cache even if the page that originally caused the
>> resource to be loaded is still being used.
> I guess. For pages that are dealing with bazillions of images then it
> makes sense to have the page discard the blobs once they're no longer in
> use. But I am very skeptical about an API that makes that happen
> automatically, because it really makes the API as a whole quite brittle.

Seems to me that onerror hooks are handy in this case, but that does 
create more work.

I've typically used  setAttribute('data-bloburl', url) when working with 
images, running revoke prior to doing a new setAttribute.

I've not started using onerror: I could certainly see using onerror and 
some other internal pointer, setAttribute('data-position', posinset) to 
refresh a blob url, recovering it when it breaks.
That doesn't help the CSS case, however.  Using automatic revocation 
with CSS makes no sense at all, I think the use here is simply for 
one-time img.src setters.

I also think that it can be accomplished without the Boolean, by 
ensuring that revoke does not take effect until the end of the event loop.

-Charles

Received on Thursday, 15 December 2011 01:17:14 UTC