Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan <arun@mozilla.com> wrote:

>  Jian,
>
>
>
>
> On 8/28/10 8:59 PM, Jian Li wrote:
>
> Adding explicit methods to window and WorkerGlobalScope seems to be a
> better solution that solves potential problems we currently have with
> blob.url. Given that, we're going to experiment the proposed new APIs in the
> WebKit implementation, That is, we will add the following two methods to
> window and WorkerGlobalScope in the WebKit implementation:
>      URLString createBlobURL(in Blob blob);
>     void revokeBlobURL(in URLString url);
>
>
> I think we're agreed here, although can anyone tell me whether there's a
> precedent on the Window object to have a method that's so specific to a
> top-level object (such as Blob)?
>

window.setInterval() comes to mind. It also has lifetime gated by the window
object, which makes it obvious that it is stopped when window unloads.
window.openDatabase() is somewhat similar, while it returns an object, that
object has useful lifetime limited by the 'window'.

  It definitely seems awkward, but I'm willing to add it to the
> specification given that there isn't really a better solution than adding
> these methods.  Also, the names seem fine to me.  Can you clarify what your
> implementation will do if createBlobURL is called twice (or more) for the
> same Blob object?
>
>  In addition, BlobError and BlobException sound better because these names
> are consistent with current "Blob" naming scheme in File API. So we're also
> going to adopt these new names in the WebKit implementation when we rename
> FileReader to BlobReader per the spec.
>
>
> *sigh.  Naming continues to be hard.  Not everyone's thrilled with the
> proliferation of Blob in the API [1] including other major implementors (my
> co-editor included ;-))  but I changed it mainly due to Darin/Jian/other
> objections.  I suppose you folks are pretty adamant on the Blob* name?
>
> -- A*
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html
>