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

Re: createBlobURL

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 19 Oct 2010 18:15:13 -0700
Message-ID: <AANLkTikYOz-2iZhPAfuCrsFXrQyvX3TedRCH1+-SD_MY@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Michael Nordman <michaeln@google.com>, arun@mozilla.com, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
On Tue, Oct 19, 2010 at 1:20 AM, Anne van Kesteren <annevk@opera.com> 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.

I would say there is one more level of indirection, since people won't
use the URL object, but rather the return value from its .href
property.

Additionally, I don't see what the value is of getting a URL object
for a blob: url is? URLs are mostly useful when resolving relative
references, but that never works for blob: urls. So we'd force people
to always create a URL object and immediately throw it away.

Another downside is that we lose the symmetry of
createObjectURL/revokeObjectURL. It's still unclear where you are
proposing the revoke function would be, but I can't think of any
syntax which would have symmetry with a constructor.

/ Jonas
Received on Wednesday, 20 October 2010 01:16:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT