W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: Lifetime of Blob URL

From: Dmitry Titov <dimich@chromium.org>
Date: Mon, 2 Aug 2010 15:22:42 -0700
Message-ID: <AANLkTimmtJ72iA3oyj7WbMRXFdw2p53gNqkBLq68TYJC@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Michael Nordman <michaeln@google.com>, David Levin <levin@google.com>, Adrian Bateman <adrianba@microsoft.com>, Darin Fisher <darin@chromium.org>, "arun@mozilla.com" <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
It feels developers will make less errors with window.getBlobUrl(blob) kind
of API, because, unlike blob.url, it doesn't violate pretty common
programming assumptions (like querying a property of the same object should
return the same value if nothing was done to the object, or that value of
property should not depend on what is a global object in the  context of the
query if the blob is the same). The spec language describing why and when
blob.url returns different values with different lifetimes would be a bit
hairy...

Agree though that functionally they are the same.

On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman <michaeln@google.com>
> wrote:
> > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman <michaeln@google.com>
> >> wrote:
> >> >
> >> >
> >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >> >>
> >> >> Sorry about the slow response. I'm currently at blackhat, so my
> >> >> internet connectivity is somewhat... unreliable, so generally having
> >> >> to try to stay off the webs :)
> >> >>
> >> >> On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov <dimich@chromium.org>
> >> >> wrote:
> >> >> > Thanks Jonas,
> >> >> > Just to clarify some details we had while discussing this, could
> you
> >> >> > confirm
> >> >> > if this matches with your thinking (or not):
> >> >> > 1. If blob was created in window1, blob.url was queried, then
> passed
> >> >> > (as
> >> >> > JS
> >> >> > object) to window2, and window1 was closed - then the url gets
> >> >> > invalidated
> >> >> > when window1 is closed, but immediately re-validated if window2
> >> >> > queries
> >> >> > blob.url. The url string is going to be the same, only there will
> be
> >> >> > a
> >> >> > time
> >> >> > interval between closing window1 and querying blob.url in window2,
> >> >> > during
> >> >> > which loading from the url returns 404.
> >> >>
> >> >> Actually, it might make sense to make blob.url, when queried by
> >> >> window2, return a different string. This makes things somewhat more
> >> >> consistent as to when a URL is working an when not.
> >> >
> >> > Now suppose window2 queries the .url attribute before window1 is
> closed?
> >> > I
> >> > think most people would expect the same value as returned in window1
> >> > (yes?).
> >> > Having the same or different value depending on whether the attribute
> >> > was
> >> > queried before or after another window was closed seems confusing. I
> >> > think
> >> > having the .url remain consistent from frame to frame/window to window
> >> > could
> >> > help with debugging.
> >>
> >> The idea would be that we *always* return different urls depending on
> >> which window queries a url. This gives the most consistent behavior in
> >> that every url given is always limited to the lifetime of the current
> >> window. No matter what windows around it does.
> >
> > If that's the idea, then I would vote for a non-instance method somewhere
> to
> > provide the context specific URL. Having a simple attribute accessor
> return
> > different values depending on which context its being accessed in is very
> > unusual behavior.
> > Can't say that its "ideal", but window.getBlobUrl(blob) and
> > window.revokeBlobUrl(...) would be an improvement.
>
> I can't say that I'm a big fan of this syntax given that I think the
> current syntax works fine in most cases. I'm definitely curious to
> hear what others think though.
>
> / Jonas
>
Received on Monday, 2 August 2010 22:23:13 GMT

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