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

Re: Discussion of File API at TPAC in Lyon

From: Dmitry Titov <dimich@chromium.org>
Date: Tue, 16 Nov 2010 12:07:11 -0800
Message-ID: <AANLkTikGPEO8a+GW93OyTEBZ6L8JGPFix0ofd9_yp_bJ@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
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>
Thanks Michael,

so the proposed change is this:  window.createObjectURL ->
window.URL.createObjectURL
and it means it's also possible to do something like this:
var otherWindow = window.open(...)
otherWindow.URL.createObjectURL(...)

Is this correct understanding?

Dmitry

On Tue, Nov 16, 2010 at 11:57 AM, Michael Nordman <michaeln@google.com>wrote:

> 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 20:07:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT