Re: Lifetime of Blob URL

Adding explicit methods to window and WorkerGlobalScope seems to be a better
solution that solves potential problems we currently have with blob.url.
Given that, we're going to experiment the proposed new APIs in the WebKit
implementation, That is, we will add the following two methods to window and
WorkerGlobalScope in the WebKit implementation:
    URLString createBlobURL(in Blob blob);
    void revokeBlobURL(in URLString url);

In addition, BlobError and BlobException sound better because these names
are consistent with current "Blob" naming scheme in File API. So we're also
going to adopt these new names in the WebKit implementation when we rename
FileReader to BlobReader per the spec.


On Mon, Aug 23, 2010 at 8:19 AM, Eric Uhrhane <ericu@google.com> wrote:

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