Re: Blob URLs | autoRevoke, defaults, and resolutions

Fwiw, to the extent it may be helpful when it comes to spec writing, here
are some quick-n-dirty thoughts about how some approximation of the
'autorevoke' behavior could be implemented in chromium.

1) Extend the lifetime of the PublicBlobURL registration until *after* the
last latchee has redeemed its ticket to ride the url. The url registration
itself is refcounted. The url registration implies the underlying data is
not reclaimable.  At time of coining the url registration, a microtask is
scheduled to release it. Latchee's may addref it safely prior to microtask
execution, keeping the url registration valid until a later balancing
release. This would be a non-compliant approximation of the way the spec is
shaping up... but good enough... maybe.... has the important
characteristics of freeing memory up eventually (generally prior to doc
unload) and guaranteeing a latchee's ticket to ride.

2) Extend the lifetime of the underlying BlobData until *after* the latchee
has redeemed its ticket to ride the url, but revoke the URL well in advance
of that. The url registration is not refcounted, The url registration
implies the underlying data is not reclaimable. There is a means to lookup
a handle to the data given the url.  The underlying blob data is
refcounted. Latchee's must take and release a ref on that. The url
registration is revoked at microtask execution time after being coined.
Piggy back a handle to the blob data on future Fetch (or other network
requests) for the PublicBlobURL. Ignore the URL when processing those
requests and refer only to the piggybacked blob data handle. Probably a
more compliant approach, but maybe more tedious to implement in chromium
(since the URL is no longer useful as the identifier for what to
fetch/load/whathaveyou, we need sideband data for that in addition to
addref/release at url latch/redemption times).

>  (I'm confused, because we've talked about this distinction several
times.)
lol, picture a herd of cats chasing their tails, you can call me calico :)


On Tue, May 7, 2013 at 1:34 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren <annevk@annevk.nl>wrote:
>
>> On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> > The only thing that's different about XHR is that the first step in my
>> > list lives in one function, and the other steps live in another
>> > function. Doesn't seem to have any effect on the discussions here
>> > other than that we'd need to define which of the two functions does
>> > the step which grabs a reference to the Blob.
>>
>> Fair enough. So I guess we can indeed fix this by changing
>> http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the
>> Blob/MediaStream/... before returning early as Arun suggested.
>>
>
> Step 1 is resolve, step 3 is fetch.  Moving it into step 1 means it would
> go in resolve, not fetch.  Putting it in fetch wouldn't help, since fetch
> doesn't always start synchronously.  (I'm confused, because we've talked
> about this distinction several times.)
>
> --
> Glenn Maynard
>
>