Re: Lifetime of Blob URL

I do not see any more discussions on blob URL API in recent days. Any more
thoughts or conclusion?

In addition, do we want to rename FileError and File Exception to BlobError
and BlobException to match with BlobReader naming, or rather keep them
intact?


On Mon, Aug 2, 2010 at 3:22 PM, Dmitry Titov <dimich@chromium.org> wrote:

> 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
>>
>
>