W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: File API: Blob URL origin

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 30 Jun 2014 19:03:31 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <885CF1DD-8AAF-4AA6-8E41-F3D9C51A16A9@mozilla.com>
To: Anne van Kesteren <annevk@annevk.nl>
On Jun 30, 2014, at 4:57 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>> They are! That is, at the time the method URL.createObjectURL(blob) is
>> called on blob, that method adds an entry to the Blob URL Store:
>> http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry
>> 
>> Iíve only defined identifier extraction for use with adding an entry. Is
>> that wrong?
> 
> It seems like you could define identifier creation, use that, use the
> return value to add an entry, and then return "blob:" + the return
> value. Creating a URL first and then parsing it again to extract
> something seems needlessly complicated.



Well, the best way to define URL.revokeObjectURL(blobURL) seemed to be in terms of parsing to extract identifier (scheme data) and then delete the entry corresponding to identifier.

But youíre absolutely right that URL.create* methods shouldnít have a dependency on the basic URL parser, and so Iíve redefined those methods along the lines you say above (namely, defining identifier creation, and then Blob URL creation).

Thatís http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking in todayís editorís draft.

(So *now* maybe the path is clear for Fetch with Blobs.)

ó A*
Received on Monday, 30 June 2014 23:04:00 UTC

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