W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: createBlobURL

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 18 Oct 2010 21:20:40 -0400
Message-ID: <4CBCF268.2040102@mozilla.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: Michael Nordman <michaeln@google.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
  On 10/18/10 8:30 PM, Jonas Sicking wrote:
> On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman<michaeln@google.com>  wrote:
>> Chrome currently has this as...
>>          DOMString createBlobURL(in Blob blob);
>>          void revokeBlobURL(in DOMString blobURL);
>> ... no prefix... on both Window and WorkerContext.
>> An important aspect of placing these interfaces on the Window and
>> WorkerContext was to scope the lifetime of the manufactured url to the
>> respective window or worker object.  I thought adam's url api was all about
>> parsing and building valid urls, so i'm not sure these methods are such a
>> good fit for that interface.
> I agree. Another thing that is nice about the window.*BlobURL() API is
> that it makes it clear which origin the created url will have. I.e.
> the origin of the window which it's called on.

I agree too, and upon reflection, I'm sorry I let myself get distracted 
by the URL API (but thanks anyway Anne for making me re-read it and 
contemplate its future ;-)).
>> Renaming to createObjectURL/revokeObjectURL seems like the most
>> straightforward way to generify the existing methods.
> I talked with Arun about this, and one argument was that we can keep
> the createBlobURL name since the returned url always uses the scheme
> 'blob'. However I have to say that I really like the
> createObjectURL/revokeObjectURL names, and it might create less
> confusion.
> So createObjectURL/revokeObjectURL has my vote.

Well, that's two implementers who have working prototypes of 
createBlobURL and revokeBlobURL, and since you and Michael are in favor 
of the name change on behalf of the implementers, that's fine by me to 
rename it :).  I'll make this change.  Moreover, no need to hold up the 
CfC on this account, since these changes are easy to make.

Future proponents of the nascent Stream API [1] can simply create 
another [Supplemental] interface (or further extend the existing one) to 
allow createObjectURL to take a Stream object and return a blob: URL.  
So that future proofs us elegantly enough.

-- A*
[1] http://dev.w3.org/html5/html-device/#stream-api
Received on Tuesday, 19 October 2010 01:21:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC