- From: Dmitry Titov <dimich@chromium.org>
- Date: Mon, 2 Aug 2010 15:22:42 -0700
- 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>
- Message-ID: <AANLkTimmtJ72iA3oyj7WbMRXFdw2p53gNqkBLq68TYJC@mail.gmail.com>
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 UTC