Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 11:14 AM, Jian Li <jianli@chromium.org> wrote:

>
>
> 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)?  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?
>>
>
> Yes, we know that everyone is working hard to try to get the best API out.
> It is just that we do not see any better solution than that.
>
> Our implementation assumes that calling window.createBlobURL() each time
> will return a new blob URL.
>
>>
>>  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?
>>
>
> I do not have any strong preference towards the naming. I just feel that it
> would be good if we could have consistent naming across File API in order to
> avoid the confusion to the developers. This is the reason I ask.
>

We could also rename to IOError/IOException with the idea that these might
be generic enough to be useful in other I/O related interfaces.

I just think it is awkward to raise a FileError/FileException in cases where
a file may not be involved; hence, my preference toward renaming
FileError/FileException to something else... BlobError/BlobException being
the obvious alternative.

-Darin



>
>> -- A*
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html
>>
>
>