Re: createBlobURL

On Tue, Oct 19, 2010 at 4:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
> > On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> Without revoking the UA has to keep around the URL-string -> resource
> >> mapping for the lifetime of the page. Which in the world of web apps
> >> can be a very long time. Even worse, in the case of dynamically
> >> created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever
> >> we'll call it), the resource has to stay around at least on the users
> >> file system for the lifetime of the page.
> >
> > So we are moving the responsibility to do things right to authors? Oh
> joy.
> > Though I suppose it might just work for the most complex of applications,
> > where they measure things such as memory usage, etc.
>
> Suggestions welcome. The base problem here is that we are doing
> resource management using a string-value rather than using a
> object-reference. It is provably impossible for the implementation to
> know if a given url is going to get used in the future (since it
> requires solving the halting problem).
>
> The only real solution here is to abandon the use of URLs-strings
> ("blob:...") and instead use some type of object which represents a
> reference to the blob/stream/whatever. Then make img.src, iframe.src,
> CSSStyleDeclaration.backgroundImage etc accept this new type in
> addition to a string.
>

I had a similar thought the other day.  However, why not just support
assigning a
Blob/Stream directly to img.src, iframe.src, etc.?  Why does there need to
be any
other representation of the data source?

(I'm not suggesting we abandon blob: URLs completely.)

-Darin



>
> I think the main mitigating factor here is that as far as memory usage
> goes, the only thing "leaked" is an entry in a hash-table, so in the
> order of 50 bytes for each generated url.
>
> / Jonas
>