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

Re: createBlobURL

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 19 Oct 2010 12:01:52 -0400
Message-ID: <4CBDC0F0.2050107@mozilla.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Michael Nordman <michaeln@google.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
  On 10/19/10 4:20 AM, Anne van Kesteren wrote:
> On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking <jonas@sicking.cc> 
> wrote:
>> 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.
>> We could maintain that even if we used a URL constructor by saying
>> that it's tied to the window whose .URL property was used as
>> constructor, but it makes it a much more indirect connection.
> It is not any less direct than how it works for new XMLHttpRequest, 
> new Worker, new EventSource, and any other number of constructors 
> where URLs are somehow involved in the objects they create. I do not 
> really see why new URL would be special here.

Fair point.  It is conceivable that the URL API can evolve to include 
creation of Blob and Stream URLs using the blob: scheme in constructors, 
including revocation mechanism for these (yes, programmer/user assisted 
revocation is necessary).  If and when that happens, we can deprecate 
these other methods (createObjectURL and revokeObjectURL).

I look forward to seeing the URL API mature into a real specification, 
and seeing some prototypes.

-- A*
Received on Tuesday, 19 October 2010 16:02:34 UTC

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