- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Oct 2010 16:57:30 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Arun Ranganathan <arun@mozilla.com>, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
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 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
Received on Tuesday, 19 October 2010 23:58:25 UTC