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'?
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 18:43:17 UTC