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

Re: Discussion of File API at TPAC in Lyon

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 16 Nov 2010 12:15:40 -0800
Message-ID: <AANLkTi=ikGwPh30k0uJCbkFenSDwy+qgch_jSB=M18df@mail.gmail.com>
To: Dmitry Titov <dimich@chromium.org>
Cc: Anne van Kesteren <annevk@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adrian Bateman <adrianba@microsoft.com>, Arun Ranganathan <aranganathan@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov <dimich@chromium.org> wrote:
> I have a clarifying question about how it would work:
> How, if at all, the lifetime of the generated urls will be defined in case
> of having those functions on URL interface object?
> If those methods are on a global object, the lifetime of the urls created
> would be gated by the lifetime of that global object, and in browser
> implementations that lifetime is usually defined well - and used for other
> things like lifetime of shared workers for example. There is certain times
> when the document/page/window are 'closed and detached', and while it varies
> in implementations and it is more complex then that, it provides a
> well-understood lifetime boundary.
> By having those methods on some static object, doesn't the lifetime becomes
> unclear? Do we grab 'current context of the call'?

We'll use the window object through which the URL object was
retrieved. So for example:

myurl1 = frames[0].URL.createObjectURL(blob);
myurl2 = frames[1].URL.createObjectURL(blob);

in this case lifetime of the two urls are bound to the lifetime of the
two different windows.

Does that make sense?

This is similar to how base-uri resolving works in XMLHttpRequest
where the base uri for a given XMLHttpRequest is determined by which
constructor was used to create it, not based by who is calling .open
or calling the constructor.

/ Jonas
Received on Tuesday, 16 November 2010 20:16:34 UTC

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