[Bug 25242] Blob.close should not set the blob's size to 0 or cause slice() to throw

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25242

--- Comment #5 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Arun from comment #3)
> (In reply to Glenn Maynard from comment #0)
> > Blob objects should be immutable, as if their data and its size never
> > change.  Blob.close() should cause reads to the blob to behave as though a
> > network resource is no longer available.  This fulfills the goal of
> > Blob.close (discarding the underlying storage), without losing immutability
> > of the Blob interface itself.
> 
> 
> Behaving as if a network resource is no longer available is right behavior,
> but only for Blobs that are accessed by network APIs. This behavior sounds
> right for CLOSED blobs that are used to coin blob: URLs. In this case, this
> behavior makes sense.

I think the analogy makes sense in general.  Another way of looking at it: if a
Blob is a File, closing the blob should act just like the user deleted the
file.

> > Another benefit of these changes is that the effects of Blob.close() are
> > narrowed.  Its only (script visible) effects during fetch, instead of having
> > lots of little side-effects scattered across the whole Blob API.  That makes
> > the API simpler for developers.
> 
> 
> But developers SHOULD see the effect of blob.close(), and in places outside
> of fetch! 

Can you give an example?  There might be use cases for a Blob.closed property
to find out if a blob is closed (if we're OK with being locked into this being
a sync operation), but that's all I can think of.

(Of course, they should see the effect of disk space being freed up if things
are working correctly, but that's not a *script-visible* effect.)

> Maybe the idea of a restricted keepalive list in bug 25302 is the right
> approach.

(Sorry, I lost the thread--is this related?)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 9 April 2014 20:27:54 UTC