- From: Michael Nordman <michaeln@google.com>
- Date: Tue, 16 Nov 2010 11:57:20 -0800
- To: Dmitry Titov <dimich@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.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'?
The intent (as i understand it) was to not change the lifetime
semantics that had been devised when these methods were defined at the
global scope, just to put a 'namespace' around them (so to speak). The
goal being a little less clutter the global namespace.
>
> Dmitry
>
> On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tuesday, November 16, 2010, Anne van Kesteren <annevk@opera.com> wrote:
>> > On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking <jonas@sicking.cc>
>> > wrote:
>> >
>> > Ok, here is what I'll propose as the final solution:
>> >
>> > FileAPI will define the following WebIDL:
>> >
>> > [Supplemental]
>> > interface URL {
>> > static DOMString createObjectURL(in Blob blob);
>> > static void revokeObjectURL(in DOMString url);
>> > };
>> >
>> > [...]
>> >
>> > Unless I hear otherwise from people, I'll assume that everyone is
>> > happy with this.
>> >
>> >
>> > This looks great. Will this make it into Firefox 4?
>>
>> Assuming we can get everyone to agree quickly enough, yes.
>>
>> / Jonas
>>
>
>
Received on Tuesday, 16 November 2010 19:57:51 UTC