W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File API "oneTimeOnly" is too poorly defined

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 28 Mar 2012 01:51:59 -0700
Message-ID: <CA+c2ei8WmYwUVMcR=tjP907UUeHUD9bK_Onpv25=KOX3zx+XAA@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Glenn Maynard <glenn@zewt.org>, public-webapps WG <public-webapps@w3.org>
On Wed, Mar 28, 2012 at 2:17 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 28 Mar 2012 08:19:55 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>> I think we need to define that APIs like xhr.open(...) and the img.src
>> setter synchronously "dereference" the URL before returning.
> What does dereferencing mean exactly?

It means "initiating the load" or some such. Implementation-wise for
blob URLs it would likely mean going through the blob-url hash table
to find the underlying Blob object and start a read from it. So if the
URL is removed from the hash using revokeObjectURL this wouldn't
affect the load. Likewise for the FileSystem API it would mean that a
read from the blob has started and so any writes need to be queued
until after the read is finished.

> xhr.open() resolves URLs currently and then xhr.send() will fetch the URL.

Yup, this is the stuff that needs to be defined. In Gecko we actually
"dereference" the URL in xhr.open which means that the caller can call
revokeObjectURL after the call to xhr.open but before xhr.send. But
it's certainly possible to change this so that the URL is dereferenced
in xhr.send instead.

/ Jonas
Received on Wednesday, 28 March 2012 08:52:59 UTC

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