Re: Lifetime of Blob URL

I agree with Dmitry: window.createBlobUrl() makes it clearer.
Querying blob.url shouldn't have side effects.
As Jonas points out, we should keep the creation and destruction
methods near each other, so window.destroyBlobUrl() would be the
opposite function.

As for getBlobUrl vs. createBlobUrl: the latter sounds like it returns
a new URL each time.  The former is less explicit.  If we're returning
a unique URL per call, then create is clearly better.  Are we
requiring that each call to xxxBlobUrl have a matched destroyBlobUrl,
even if we're returning the same URL?

I think BlobError and BlobException make a bit more sense, but I'm not
too adamant about it.

On Sat, Aug 21, 2010 at 1:00 PM, Jian Li <jianli@google.com> wrote:
> 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
>>
>
>

Received on Monday, 23 August 2010 15:20:38 UTC