On Tue, Oct 19, 2010 at 4:57 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren <ann...@opera.com> > wrote: > > On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking <jo...@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 >