Re: Lifetime of Blob URL
OK, thank you Darin :) This alleviates the naming tension.
FileReader, FileException, and FileError it is, then.
(Eliminating Blob from the inheritance hierarchy causes the problems Darin
mentions below).
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren < ann...@opera.com > wrote:
On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher < da...@chromium.org > wrote:
Another idea (possibly a crazy one) would be to eliminate Blob, and just use
File for everything. We could rename BlobBuilder to FileBuilder and have it
return a File instead of a Blob. Same goes for Blob.slice(). Of course,
the File would not necessarily correspond to a real physical file on disk
for performance reasons.
Not having Blob at all works for me!
I gave this some more thought. Here's some issues I came up with:
1) BlobBuilder -> FileBuilder
This renaming seems to suggest the creation of a file, which is not the intent
at all.
2) XHR.{asBlob,responseBlob} -> XHR.{asFile,responseFile}
This renaming seems to suggest the creation of a file, which is not necessary
for small responses.
3) Combine Blob and File into a single File interface
This merging has the unfortunate side-effect of introducing a "name" property
for the result of a
File.slice() operation. It also means that the result of FileBuilder and
XHR.responseFile would
have a name.
Considering the above, it seems like there is a place for Blob (or something
like it).
I can see Jonas' points about BlobReader vs. FileReader, and so I'm happy to
backpedal and go with
FileReader, FileException, and FileError, keeping Blob for cases where we don't
promise a file.
-Darin
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren wrote:
> On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher
> wrote:
>
>> Another idea (possibly a crazy one) would be to eliminate Blob, and just
>> use File for everything. We could rename BlobBuilder to FileBuilder and
>> have it return a File instead of a Blob. Same goes for Blob.slice(). Of
>> course,
>> the File would not necessarily correspond to a real physical file on disk
>> for performance reasons.
>>
>
> Not having Blob at all works for me!
>
>
>
I gave this some more thought. Here's some issues I came up with:
1) BlobBuilder -> FileBuilder
This renaming seems to suggest the creation of a file, which is not the
intent at all.
2) XHR.{asBlob,responseBlob} -> XHR.{asFile,responseFile}
This renaming seems to suggest the creation of a file, which is not
necessary for small responses.
3) Combine Blob and File into a single File interface
This merging has the unfortunate side-effect of introducing a "name"
property for the result of a
File.slice() operation. It also means that the result of FileBuilder and
XHR.responseFile would
have a name.
Considering the above, it seems like there is a place for Blob (or something
like it).
I can see Jonas' points about BlobReader vs. FileReader, and so I'm happy to
backpedal and go with
FileReader, FileException, and FileError, keeping Blob for cases where we
don't promise a file.
-Darin
Re: Lifetime of Blob URL
On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher wrote: Another idea (possibly a crazy one) would be to eliminate Blob, and just use File for everything. We could rename BlobBuilder to FileBuilder and have it return a File instead of a Blob. Same goes for Blob.slice(). Of course, the File would not necessarily correspond to a real physical file on disk for performance reasons. Not having Blob at all works for me! -- Anne van Kesteren http://annevankesteren.nl/
Re: Lifetime of Blob URL
As a developer who eagerly awaits this API, I'm fine with using File-
prefixes for most everything, since many times a "file" in many APIs is
really an abstraction for a stream of data anyway, and I think that most
experienced developers can wrap their heads around that.
That's my two cent's worth,
Mike
On Mon, Aug 30, 2010 at 5:25 PM, Jonas Sicking wrote:
> On Mon, Aug 30, 2010 at 5:23 PM, Jian Li wrote:
> > The other alternative is to have both FileReader and BlobReader, while
> the
> > former one is for reading only File object and the later one is for
> reading
> > any Blob object. With that, we also have FileReaderSync and
> BlobReaderSync.
>
> That seems like an excessive solution to the "you can read blobs with
> FileReader even though 'blob' isn't in the name" problem.
>
> / Jonas
>
> > On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking wrote:
> >>
> >> On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov
> wrote:
> >> > As for wild ideas, it also could be something more generic, lets say
> >> > DataReader which can take Blobs and Files (and perhaps something else
> in
> >> > the
> >> > future). Like XHR that has overloaded methods for xhr.open(..).
> >> > It seems possible that web developers may not realize that File is
> >> > actually
> >> > a Blob and may be confused by using BlobReader to read File. ("Do I
> need
> >> > to
> >> > make a Blob out of my File first?"). They may be equally confused by
> >> > using
> >> > FileReader to read Blob though.
> >>
> >> That would address item 1 on my list. But not item 2 through 4.
> >>
> >> / Jonas
> >>
> >> > On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking
> wrote:
> >> >>
> >> >> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher
> >> >> wrote:
> >> >> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan <
> a...@mozilla.com>
> >> >> >> wrote:
> >> >> >> >> 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.
> >> >> >> >
> >> >> >> > *sigh. Naming continues to be hard. Not everyone's thrilled
> with
> >> >> >> > the
> >> >> >> > proliferation of Blob in the API [1] including other major
> >> >> >> > implementors
> >> >> >> > (my
> >> >> >> > co-editor included ;-)) but I changed it mainly due to
> >> >> >> > Darin/Jian/other
> >> >> >> > objections. I suppose you folks are pretty adamant on the Blob*
> >> >> >> > name?
> >> >> >>
> >> >> >> I feel pretty strongly that we should name this back to
> FileReader,
> >> >> >> for several reasons:
> >> >> >>
> >> >> >> 1. Most people that I talk to dislike the name Blob, much less
> >> >> >> having
> >> >> >> it spread to things like BlobReader.
> >> >> >> 2. My understanding is that the writer counterpart is going to be
> >> >> >> called FileWriter (is this correct?)
> >> >> >
> >> >> > Yes, that is what we are currently implementing in WebKit.
> >> >> >
> >> >> >>
> >> >> >> 3. While it's certainly possible to read Blobs with this, it seems
> >> >> >> to
> >> >> >> me like the far most common case will be to read a "real" file, or
> >> >> >> part of a file (i.e. the result from myfile.slice()).
> >> >> >>
> >> >> >> 4. There is one shipping implementation of FileReader
> >> >> >>
> >> >> >
> >> >> > It just seems odd to use an interface named FileReader to read
> blobs,
> >> >> > which
> >> >> > may not correspond to files. Consider BlobBuilder, which can be
> used
> >> >> > to
> >> >> > construct a Blob from a string.
> >> >>
> >> >> I somewhat agree. But it seems equally strange to use BlobReader to
> >> >> read files, and I suspect that it will be vastly more common to read
> >> >> files than blobs-that-aren't-files.
> >> >>
> >> >> Yes, the File interface inherits Blob, so technically when you're
> >> >> reading a file you're also reading a blob, but I doubt that is the
> >> >> mental model most people will have.
> >> >>
> >> >> Like so many other things, there is no perfect solution here.
> >> >>
> >> >> > Another idea (possibly a crazy one) would be to eliminate Blob, and
> >> >> > just
> >> >> > use
> >> >> > File for everything. We could rename BlobBuilder to FileBuilder
> and
> >> >> > have it
> >> >> > return a File instead of a Blob. Same goes for Blob.slice(). Of
> >> >> > course,
> >> >> > the File would not necessarily correspond to a real physical file
> on
> >> >> > disk
> >> >> > for performance reasons.
> >> >>
> >> >> I've been thinking about this too. I can't say I feel strongly either
> >> >> way. It feels somewhat strange, but I can't come up with any solid
> >> >> technical reasons against it.
> >> >>
> >> >> / Jonas
> >> >
> >> >
> >
> >
>
>
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 5:23 PM, Jian Li wrote:
> The other alternative is to have both FileReader and BlobReader, while the
> former one is for reading only File object and the later one is for reading
> any Blob object. With that, we also have FileReaderSync and BlobReaderSync.
That seems like an excessive solution to the "you can read blobs with
FileReader even though 'blob' isn't in the name" problem.
/ Jonas
> On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking wrote:
>>
>> On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov wrote:
>> > As for wild ideas, it also could be something more generic, lets say
>> > DataReader which can take Blobs and Files (and perhaps something else in
>> > the
>> > future). Like XHR that has overloaded methods for xhr.open(..).
>> > It seems possible that web developers may not realize that File is
>> > actually
>> > a Blob and may be confused by using BlobReader to read File. ("Do I need
>> > to
>> > make a Blob out of my File first?"). They may be equally confused by
>> > using
>> > FileReader to read Blob though.
>>
>> That would address item 1 on my list. But not item 2 through 4.
>>
>> / Jonas
>>
>> > On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking wrote:
>> >>
>> >> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher
>> >> wrote:
>> >> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan
>> >> >> wrote:
>> >> >> >> 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.
>> >> >> >
>> >> >> > *sigh. Naming continues to be hard. Not everyone's thrilled with
>> >> >> > the
>> >> >> > proliferation of Blob in the API [1] including other major
>> >> >> > implementors
>> >> >> > (my
>> >> >> > co-editor included ;-)) but I changed it mainly due to
>> >> >> > Darin/Jian/other
>> >> >> > objections. I suppose you folks are pretty adamant on the Blob*
>> >> >> > name?
>> >> >>
>> >> >> I feel pretty strongly that we should name this back to FileReader,
>> >> >> for several reasons:
>> >> >>
>> >> >> 1. Most people that I talk to dislike the name Blob, much less
>> >> >> having
>> >> >> it spread to things like BlobReader.
>> >> >> 2. My understanding is that the writer counterpart is going to be
>> >> >> called FileWriter (is this correct?)
>> >> >
>> >> > Yes, that is what we are currently implementing in WebKit.
>> >> >
>> >> >>
>> >> >> 3. While it's certainly possible to read Blobs with this, it seems
>> >> >> to
>> >> >> me like the far most common case will be to read a "real" file, or
>> >> >> part of a file (i.e. the result from myfile.slice()).
>> >> >>
>> >> >> 4. There is one shipping implementation of FileReader
>> >> >>
>> >> >
>> >> > It just seems odd to use an interface named FileReader to read blobs,
>> >> > which
>> >> > may not correspond to files. Consider BlobBuilder, which can be used
>> >> > to
>> >> > construct a Blob from a string.
>> >>
>> >> I somewhat agree. But it seems equally strange to use BlobReader to
>> >> read files, and I suspect that it will be vastly more common to read
>> >> files than blobs-that-aren't-files.
>> >>
>> >> Yes, the File interface inherits Blob, so technically when you're
>> >> reading a file you're also reading a blob, but I doubt that is the
>> >> mental model most people will have.
>> >>
>> >> Like so many other things, there is no perfect solution here.
>> >>
>> >> > Another idea (possibly a crazy one) would be to eliminate Blob, and
>> >> > just
>> >> > use
>> >> > File for everything. We could rename BlobBuilder to FileBuilder and
>> >> > have it
>> >> > return a File instead of a Blob. Same goes for Blob.slice(). Of
>> >> > course,
>> >> > the File would not necessarily correspond to a real physical file on
>> >> > disk
>> >> > for performance reasons.
>> >>
>> >> I've been thinking about this too. I can't say I feel strongly either
>> >> way. It feels somewhat strange, but I can't come up with any solid
>> >> technical reasons against it.
>> >>
>> >> / Jonas
>> >
>> >
>
>
Re: Lifetime of Blob URL
The other alternative is to have both FileReader and BlobReader, while the
former one is for reading only File object and the later one is for reading
any Blob object. With that, we also have FileReaderSync and BlobReaderSync.
On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking wrote:
> On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov wrote:
> > As for wild ideas, it also could be something more generic, lets say
> > DataReader which can take Blobs and Files (and perhaps something else in
> the
> > future). Like XHR that has overloaded methods for xhr.open(..).
> > It seems possible that web developers may not realize that File is
> actually
> > a Blob and may be confused by using BlobReader to read File. ("Do I need
> to
> > make a Blob out of my File first?"). They may be equally confused by
> using
> > FileReader to read Blob though.
>
> That would address item 1 on my list. But not item 2 through 4.
>
> / Jonas
>
> > On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking wrote:
> >>
> >> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher
> wrote:
> >> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking
> wrote:
> >> >>
> >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan
> >> >> wrote:
> >> >> >> 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.
> >> >> >
> >> >> > *sigh. Naming continues to be hard. Not everyone's thrilled with
> >> >> > the
> >> >> > proliferation of Blob in the API [1] including other major
> >> >> > implementors
> >> >> > (my
> >> >> > co-editor included ;-)) but I changed it mainly due to
> >> >> > Darin/Jian/other
> >> >> > objections. I suppose you folks are pretty adamant on the Blob*
> >> >> > name?
> >> >>
> >> >> I feel pretty strongly that we should name this back to FileReader,
> >> >> for several reasons:
> >> >>
> >> >> 1. Most people that I talk to dislike the name Blob, much less having
> >> >> it spread to things like BlobReader.
> >> >> 2. My understanding is that the writer counterpart is going to be
> >> >> called FileWriter (is this correct?)
> >> >
> >> > Yes, that is what we are currently implementing in WebKit.
> >> >
> >> >>
> >> >> 3. While it's certainly possible to read Blobs with this, it seems to
> >> >> me like the far most common case will be to read a "real" file, or
> >> >> part of a file (i.e. the result from myfile.slice()).
> >> >>
> >> >> 4. There is one shipping implementation of FileReader
> >> >>
> >> >
> >> > It just seems odd to use an interface named FileReader to read blobs,
> >> > which
> >> > may not correspond to files. Consider BlobBuilder, which can be used
> to
> >> > construct a Blob from a string.
> >>
> >> I somewhat agree. But it seems equally strange to use BlobReader to
> >> read files, and I suspect that it will be vastly more common to read
> >> files than blobs-that-aren't-files.
> >>
> >> Yes, the File interface inherits Blob, so technically when you're
> >> reading a file you're also reading a blob, but I doubt that is the
> >> mental model most people will have.
> >>
> >> Like so many other things, there is no perfect solution here.
> >>
> >> > Another idea (possibly a crazy one) would be to eliminate Blob, and
> just
> >> > use
> >> > File for everything. We could rename BlobBuilder to FileBuilder and
> >> > have it
> >> > return a File instead of a Blob. Same goes for Blob.slice(). Of
> >> > course,
> >> > the File would not necessarily correspond to a real physical file on
> >> > disk
> >> > for performance reasons.
> >>
> >> I've been thinking about this too. I can't say I feel strongly either
> >> way. It feels somewhat strange, but I can't come up with any solid
> >> technical reasons against it.
> >>
> >> / Jonas
> >
> >
>
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov wrote:
> As for wild ideas, it also could be something more generic, lets say
> DataReader which can take Blobs and Files (and perhaps something else in the
> future). Like XHR that has overloaded methods for xhr.open(..).
> It seems possible that web developers may not realize that File is actually
> a Blob and may be confused by using BlobReader to read File. ("Do I need to
> make a Blob out of my File first?"). They may be equally confused by using
> FileReader to read Blob though.
That would address item 1 on my list. But not item 2 through 4.
/ Jonas
> On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking wrote:
>>
>> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher wrote:
>> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote:
>> >>
>> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan
>> >> wrote:
>> >> >> 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.
>> >> >
>> >> > *sigh. Naming continues to be hard. Not everyone's thrilled with
>> >> > the
>> >> > proliferation of Blob in the API [1] including other major
>> >> > implementors
>> >> > (my
>> >> > co-editor included ;-)) but I changed it mainly due to
>> >> > Darin/Jian/other
>> >> > objections. I suppose you folks are pretty adamant on the Blob*
>> >> > name?
>> >>
>> >> I feel pretty strongly that we should name this back to FileReader,
>> >> for several reasons:
>> >>
>> >> 1. Most people that I talk to dislike the name Blob, much less having
>> >> it spread to things like BlobReader.
>> >> 2. My understanding is that the writer counterpart is going to be
>> >> called FileWriter (is this correct?)
>> >
>> > Yes, that is what we are currently implementing in WebKit.
>> >
>> >>
>> >> 3. While it's certainly possible to read Blobs with this, it seems to
>> >> me like the far most common case will be to read a "real" file, or
>> >> part of a file (i.e. the result from myfile.slice()).
>> >>
>> >> 4. There is one shipping implementation of FileReader
>> >>
>> >
>> > It just seems odd to use an interface named FileReader to read blobs,
>> > which
>> > may not correspond to files. Consider BlobBuilder, which can be used to
>> > construct a Blob from a string.
>>
>> I somewhat agree. But it seems equally strange to use BlobReader to
>> read files, and I suspect that it will be vastly more common to read
>> files than blobs-that-aren't-files.
>>
>> Yes, the File interface inherits Blob, so technically when you're
>> reading a file you're also reading a blob, but I doubt that is the
>> mental model most people will have.
>>
>> Like so many other things, there is no perfect solution here.
>>
>> > Another idea (possibly a crazy one) would be to eliminate Blob, and just
>> > use
>> > File for everything. We could rename BlobBuilder to FileBuilder and
>> > have it
>> > return a File instead of a Blob. Same goes for Blob.slice(). Of
>> > course,
>> > the File would not necessarily correspond to a real physical file on
>> > disk
>> > for performance reasons.
>>
>> I've been thinking about this too. I can't say I feel strongly either
>> way. It feels somewhat strange, but I can't come up with any solid
>> technical reasons against it.
>>
>> / Jonas
>
>
Re: Lifetime of Blob URL
As for wild ideas, it also could be something more generic, lets say
DataReader which can take Blobs and Files (and perhaps something else in the
future). Like XHR that has overloaded methods for xhr.open(..).
It seems possible that web developers may not realize that File is actually
a Blob and may be confused by using BlobReader to read File. ("Do I need to
make a Blob out of my File first?"). They may be equally confused by using
FileReader to read Blob though.
On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking wrote:
> On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher wrote:
> > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote:
> >>
> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan
> >> wrote:
> >> >> 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.
> >> >
> >> > *sigh. Naming continues to be hard. Not everyone's thrilled with the
> >> > proliferation of Blob in the API [1] including other major
> implementors
> >> > (my
> >> > co-editor included ;-)) but I changed it mainly due to
> Darin/Jian/other
> >> > objections. I suppose you folks are pretty adamant on the Blob* name?
> >>
> >> I feel pretty strongly that we should name this back to FileReader,
> >> for several reasons:
> >>
> >> 1. Most people that I talk to dislike the name Blob, much less having
> >> it spread to things like BlobReader.
> >> 2. My understanding is that the writer counterpart is going to be
> >> called FileWriter (is this correct?)
> >
> > Yes, that is what we are currently implementing in WebKit.
> >
> >>
> >> 3. While it's certainly possible to read Blobs with this, it seems to
> >> me like the far most common case will be to read a "real" file, or
> >> part of a file (i.e. the result from myfile.slice()).
> >>
> >> 4. There is one shipping implementation of FileReader
> >>
> >
> > It just seems odd to use an interface named FileReader to read blobs,
> which
> > may not correspond to files. Consider BlobBuilder, which can be used to
> > construct a Blob from a string.
>
> I somewhat agree. But it seems equally strange to use BlobReader to
> read files, and I suspect that it will be vastly more common to read
> files than blobs-that-aren't-files.
>
> Yes, the File interface inherits Blob, so technically when you're
> reading a file you're also reading a blob, but I doubt that is the
> mental model most people will have.
>
> Like so many other things, there is no perfect solution here.
>
> > Another idea (possibly a crazy one) would be to eliminate Blob, and just
> use
> > File for everything. We could rename BlobBuilder to FileBuilder and have
> it
> > return a File instead of a Blob. Same goes for Blob.slice(). Of course,
> > the File would not necessarily correspond to a real physical file on disk
> > for performance reasons.
>
> I've been thinking about this too. I can't say I feel strongly either
> way. It feels somewhat strange, but I can't come up with any solid
> technical reasons against it.
>
> / Jonas
>
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher wrote: > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote: >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan >> wrote: >> >> 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. >> > >> > *sigh. Naming continues to be hard. Not everyone's thrilled with the >> > proliferation of Blob in the API [1] including other major implementors >> > (my >> > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other >> > objections. I suppose you folks are pretty adamant on the Blob* name? >> >> I feel pretty strongly that we should name this back to FileReader, >> for several reasons: >> >> 1. Most people that I talk to dislike the name Blob, much less having >> it spread to things like BlobReader. >> 2. My understanding is that the writer counterpart is going to be >> called FileWriter (is this correct?) > > Yes, that is what we are currently implementing in WebKit. > >> >> 3. While it's certainly possible to read Blobs with this, it seems to >> me like the far most common case will be to read a "real" file, or >> part of a file (i.e. the result from myfile.slice()). >> >> 4. There is one shipping implementation of FileReader >> > > It just seems odd to use an interface named FileReader to read blobs, which > may not correspond to files. Consider BlobBuilder, which can be used to > construct a Blob from a string. I somewhat agree. But it seems equally strange to use BlobReader to read files, and I suspect that it will be vastly more common to read files than blobs-that-aren't-files. Yes, the File interface inherits Blob, so technically when you're reading a file you're also reading a blob, but I doubt that is the mental model most people will have. Like so many other things, there is no perfect solution here. > Another idea (possibly a crazy one) would be to eliminate Blob, and just use > File for everything. We could rename BlobBuilder to FileBuilder and have it > return a File instead of a Blob. Same goes for Blob.slice(). Of course, > the File would not necessarily correspond to a real physical file on disk > for performance reasons. I've been thinking about this too. I can't say I feel strongly either way. It feels somewhat strange, but I can't come up with any solid technical reasons against it. / Jonas
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote: > On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan > wrote: > >> 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. > > > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > > proliferation of Blob in the API [1] including other major implementors > (my > > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > > objections. I suppose you folks are pretty adamant on the Blob* name? > > I feel pretty strongly that we should name this back to FileReader, > for several reasons: > > 1. Most people that I talk to dislike the name Blob, much less having > it spread to things like BlobReader. > 2. My understanding is that the writer counterpart is going to be > called FileWriter (is this correct?) > Yes, that is what we are currently implementing in WebKit. > 3. While it's certainly possible to read Blobs with this, it seems to > me like the far most common case will be to read a "real" file, or > part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader > > It just seems odd to use an interface named FileReader to read blobs, which may not correspond to files. Consider BlobBuilder, which can be used to construct a Blob from a string. Another idea (possibly a crazy one) would be to eliminate Blob, and just use File for everything. We could rename BlobBuilder to FileBuilder and have it return a File instead of a Blob. Same goes for Blob.slice(). Of course, the File would not necessarily correspond to a real physical file on disk for performance reasons. -Darin
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: >> 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. > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > proliferation of Blob in the API [1] including other major implementors (my > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > objections. I suppose you folks are pretty adamant on the Blob* name? I feel pretty strongly that we should name this back to FileReader, for several reasons: 1. Most people that I talk to dislike the name Blob, much less having it spread to things like BlobReader. 2. My understanding is that the writer counterpart is going to be called FileWriter (is this correct?) 3. While it's certainly possible to read Blobs with this, it seems to me like the far most common case will be to read a "real" file, or part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader / Jonas
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > Jian, > > > > > On 8/28/10 8:59 PM, Jian Li wrote: > > 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); > > > I think we're agreed here, although can anyone tell me whether there's a > precedent on the Window object to have a method that's so specific to a > top-level object (such as Blob)? > window.setInterval() comes to mind. It also has lifetime gated by the window object, which makes it obvious that it is stopped when window unloads. window.openDatabase() is somewhat similar, while it returns an object, that object has useful lifetime limited by the 'window'. It definitely seems awkward, but I'm willing to add it to the > specification given that there isn't really a better solution than adding > these methods. Also, the names seem fine to me. Can you clarify what your > implementation will do if createBlobURL is called twice (or more) for the > same Blob object? > > 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. > > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > proliferation of Blob in the API [1] including other major implementors (my > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > objections. I suppose you folks are pretty adamant on the Blob* name? > > -- A* > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html >
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 11:14 AM, Jian Li wrote: > > > On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > >> Jian, >> >> >> >> >> On 8/28/10 8:59 PM, Jian Li wrote: >> >> 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); >> >> >> I think we're agreed here, although can anyone tell me whether there's a >> precedent on the Window object to have a method that's so specific to a >> top-level object (such as Blob)? It definitely seems awkward, but I'm >> willing to add it to the specification given that there isn't really a >> better solution than adding these methods. Also, the names seem fine to >> me. Can you clarify what your implementation will do if createBlobURL is >> called twice (or more) for the same Blob object? >> > > Yes, we know that everyone is working hard to try to get the best API out. > It is just that we do not see any better solution than that. > > Our implementation assumes that calling window.createBlobURL() each time > will return a new blob 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. >> >> >> *sigh. Naming continues to be hard. Not everyone's thrilled with the >> proliferation of Blob in the API [1] including other major implementors (my >> co-editor included ;-)) but I changed it mainly due to Darin/Jian/other >> objections. I suppose you folks are pretty adamant on the Blob* name? >> > > I do not have any strong preference towards the naming. I just feel that it > would be good if we could have consistent naming across File API in order to > avoid the confusion to the developers. This is the reason I ask. > We could also rename to IOError/IOException with the idea that these might be generic enough to be useful in other I/O related interfaces. I just think it is awkward to raise a FileError/FileException in cases where a file may not be involved; hence, my preference toward renaming FileError/FileException to something else... BlobError/BlobException being the obvious alternative. -Darin > >> -- A* >> >> [1] >> http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html >> > >
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > Jian, > > > > > On 8/28/10 8:59 PM, Jian Li wrote: > > 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); > > > I think we're agreed here, although can anyone tell me whether there's a > precedent on the Window object to have a method that's so specific to a > top-level object (such as Blob)? It definitely seems awkward, but I'm > willing to add it to the specification given that there isn't really a > better solution than adding these methods. Also, the names seem fine to > me. Can you clarify what your implementation will do if createBlobURL is > called twice (or more) for the same Blob object? > Yes, we know that everyone is working hard to try to get the best API out. It is just that we do not see any better solution than that. Our implementation assumes that calling window.createBlobURL() each time will return a new blob 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. > > > *sigh. Naming continues to be hard. Not everyone's thrilled with the > proliferation of Blob in the API [1] including other major implementors (my > co-editor included ;-)) but I changed it mainly due to Darin/Jian/other > objections. I suppose you folks are pretty adamant on the Blob* name? > I do not have any strong preference towards the naming. I just feel that it would be good if we could have consistent naming across File API in order to avoid the confusion to the developers. This is the reason I ask. > > -- A* > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html >
Re: Lifetime of Blob URL
Jian, On 8/28/10 8:59 PM, Jian Li wrote: 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); I think we're agreed here, although can anyone tell me whether there's a precedent on the Window object to have a method that's so specific to a top-level object (such as Blob)? It definitely seems awkward, but I'm willing to add it to the specification given that there isn't really a better solution than adding these methods. Also, the names seem fine to me. Can you clarify what your implementation will do if createBlobURL is called twice (or more) for the same Blob object? 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. *sigh. Naming continues to be hard. Not everyone's thrilled with the proliferation of Blob in the API [1] including other major implementors (my co-editor included ;-)) but I changed it mainly due to Darin/Jian/other objections. I suppose you folks are pretty adamant on the Blob* name? -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0153.html
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 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 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 > 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 wrote: > >>> > >>> On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman > >>> wrote: > >>> > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking > wrote: > >>> >> > >>> >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman > >>> >> > >>> >> wrote: > >>> >> > > >>> >> > > >>> >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking > >>> >> > 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 < > dim...@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 t
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 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 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 wrote: >>> >>> On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman >>> wrote: >>> > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking wrote: >>> >> >>> >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman >>> >> >>> >> wrote: >>> >> > >>> >> > >>> >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking >>> >> > 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 >>> >> >> 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 >> > >
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 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 wrote: > >> On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman >> wrote: >> > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking wrote: >> >> >> >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman > > >> >> wrote: >> >> > >> >> > >> >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking >> 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 >> >> >> 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 >> > >
Re: Lifetime of Blob URL
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 wrote: > On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman > wrote: > > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking wrote: > >> > >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman > >> wrote: > >> > > >> > > >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking > 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 > >> >> 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 >
Re: Lifetime of Blob URL
On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman wrote: > On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking wrote: >> >> On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman >> wrote: >> > >> > >> > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking 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 >> >> 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
Re: Lifetime of Blob URL
On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking wrote: > On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman > wrote: > > > > > > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking 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 > 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. > > Without fully understanding the gap between blob and .url life time, some > > folks are going to be mystified by when/why a url value stops working, or > > why the .url value is sometimes different than it was before. There are > some > > pretty hidden side affect of accessing that attribute in a particular > frame. > > These subtle oddities with the .url attribute are in part > > what originally motivated the proposal to make it more explicit. > > We're trying to make blob.url easy and natural feeling, but with too many > > caveats, will it be? > > I guess that's a long winded vote for resurrecting the same url value > used > > in window1 in the particular case Dmitry raised. > > I totally agree that this is not an ideal solution. However as far as > I can see there are no ideal solutions. The basic problem is that we > are using a string to reference a resource, and there is no way to let > a string value keep a resource alive. > > Usually resource management is done by holding a reference to that > resource. Once there no longer are references to the resource the > resource can be deleted without anyone noticing. Ideal would be if you > could set: > > myImageElement.srcFile = myFile; > > However that would force us to add API to every single API that deals > with urls, thus making that option too non-ideal. Instead we have > chosen to have the ability to extract a url-string from the file, > leaving us with other non-ideal behavior in the case when a url is > transferred between windows. > > / Jonas >
Re: Lifetime of Blob URL
On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman wrote: > > > On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking 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 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. > Without fully understanding the gap between blob and .url life time, some > folks are going to be mystified by when/why a url value stops working, or > why the .url value is sometimes different than it was before. There are some > pretty hidden side affect of accessing that attribute in a particular frame. > These subtle oddities with the .url attribute are in part > what originally motivated the proposal to make it more explicit. > We're trying to make blob.url easy and natural feeling, but with too many > caveats, will it be? > I guess that's a long winded vote for resurrecting the same url value used > in window1 in the particular case Dmitry raised. I totally agree that this is not an ideal solution. However as far as I can see there are no ideal solutions. The basic problem is that we are using a string to reference a resource, and there is no way to let a string value keep a resource alive. Usually resource management is done by holding a reference to that resource. Once there no longer are references to the resource the resource can be deleted without anyone noticing. Ideal would be if you could set: myImageElement.srcFile = myFile; However that would force us to add API to every single API that deals with urls, thus making that option too non-ideal. Instead we have chosen to have the ability to extract a url-string from the file, leaving us with other non-ideal behavior in the case when a url is transferred between windows. / Jonas
Re: Lifetime of Blob URL
On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking 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 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. Without fully understanding the gap between blob and .url life time, some folks are going to be mystified by when/why a url value stops working, or why the .url value is sometimes different than it was before. There are some pretty hidden side affect of accessing that attribute in a particular frame. These subtle oddities with the .url attribute are in part what originally motivated the proposal to make it more explicit. We're trying to make blob.url easy and natural feeling, but with too many caveats, will it be? I guess that's a long winded vote for resurrecting the same url value used in window1 in the particular case Dmitry raised. > > I.e. you're less likely to end up covering up a bug due to a URL > coming back to life because another page started using a blob whose > URL you were previously handed. > > It's a somewhat unlikely scenario so I don't feel very strongly either way. > > > 2. If blob is sent to a Worker via worker.postMessage(blob), the > 'structured > > clone' mechanism is used, so on the other side of postMessage a new blob > > object is created, backed by the same data, but having its own unique > > blob.url string (and separate lifetime). > > Yes. > > / Jonas > > > On Mon, Jul 26, 2010 at 2:12 PM, Jonas Sicking wrote: > >> > >> On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: > >> > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman < > adria...@microsoft.com> > >> > wrote: > >> >> > >> >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > >> >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin > >> >> > wrote: > >> >> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman > >> >> > > >> >> > wrote: > >> >> > I read point #5 to be only about surviving the start of a > navigation. > >> >> > As > >> >> > a > >> >> > web developer, how can I tell when a load has started for an ? > >> >> > Isn't > >> >> > this similarly indeterminate. > >> >> > > >> >> > As soon as img.src is set. > >> >> > > >> >> > "the spec could mention that the resource pointed by blob URL > should > >> >> > be > >> >> > loaded successfully as long as the blob URL is valid at the time > when > >> >> > the > >> >> > resource is starting to load." > >> >> > > >> >> > Should apply to xhr (after send is called), img, and navigation. > >> >> > > >> >> > Right, it seems reasonable to say that ownership of the resource > >> >> > referenced > >> >> > by a Blob can be shared by a XHR, Image, or navigation once it is > >> >> > told > >> >> > to > >> >> > start loading the resource. > >> >> > > >> >> > -Darin > >> >> > >> >> It sounds like you are saying the following is guaranteed to work: > >> >> > >> >> img.src = blob.url; > >> >> window.revokeBlobUrl(blob); > >> >> return; > >> >> > >> >> If that is the case then the user agent is already making the > >> >> guarantees > >> >> I was talking about and so I still think having the lifetime mapped > to > >> >> the > >> >> blob > >> >> not the document is better. This means that in the general case I > don't > >> >> have > >> >> to worry about lifetime management. > >> > > >> > Mapping lifetime to the blob exposes when the blob gets garbage > >> > collected > >> > which is a very indeterminate point in time (and is very browser > version > >> > dependent -- it will set you up for compatibility issues when you > update > >> > your javascript engine -- and there are also the cross browser issues > of > >> > course). > >> > Specifically, a blob could go "out of scope" (to use your earlier > >> > phrase) > >> > and then one could do im
Lifetime of Blob URL
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 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. I.e. you're less likely to end up covering up a bug due to a URL coming back to life because another page started using a blob whose URL you were previously handed. It's a somewhat unlikely scenario so I don't feel very strongly either way. > 2. If blob is sent to a Worker via worker.postMessage(blob), the 'structured > clone' mechanism is used, so on the other side of postMessage a new blob > object is created, backed by the same data, but having its own unique > blob.url string (and separate lifetime). Yes. / Jonas > On Mon, Jul 26, 2010 at 2:12 PM, Jonas Sicking wrote: >> >> On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: >> > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman >> > wrote: >> >> >> >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: >> >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin >> >> > wrote: >> >> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman >> >> > >> >> > wrote: >> >> > I read point #5 to be only about surviving the start of a navigation. >> >> > As >> >> > a >> >> > web developer, how can I tell when a load has started for an ? >> >> > Isn't >> >> > this similarly indeterminate. >> >> > >> >> > As soon as img.src is set. >> >> > >> >> > "the spec could mention that the resource pointed by blob URL should >> >> > be >> >> > loaded successfully as long as the blob URL is valid at the time when >> >> > the >> >> > resource is starting to load." >> >> > >> >> > Should apply to xhr (after send is called), img, and navigation. >> >> > >> >> > Right, it seems reasonable to say that ownership of the resource >> >> > referenced >> >> > by a Blob can be shared by a XHR, Image, or navigation once it is >> >> > told >> >> > to >> >> > start loading the resource. >> >> > >> >> > -Darin >> >> >> >> It sounds like you are saying the following is guaranteed to work: >> >> >> >> img.src = blob.url; >> >> window.revokeBlobUrl(blob); >> >> return; >> >> >> >> If that is the case then the user agent is already making the >> >> guarantees >> >> I was talking about and so I still think having the lifetime mapped to >> >> the >> >> blob >> >> not the document is better. This means that in the general case I don't >> >> have >> >> to worry about lifetime management. >> > >> > Mapping lifetime to the blob exposes when the blob gets garbage >> > collected >> > which is a very indeterminate point in time (and is very browser version >> > dependent -- it will set you up for compatibility issues when you update >> > your javascript engine -- and there are also the cross browser issues of >> > course). >> > Specifically, a blob could go "out of scope" (to use your earlier >> > phrase) >> > and then one could do img.src = blobUrl (the url that was exposed from >> > the >> > blob but not using the blob object). This will work sometimes but not >> > others >> > (depending on whether garbage collection collected the blob). >> > This is much more indeterminate than the current spec which maps the >> > blob.url lifetime to the lifetime of the document where the blob was >> > created. >> > When thinking about blob.url lifetime, there are several problems to >> > solve: >> > 1. "An AJAX style web application may never navigate the document and >> > this >> > means that every blob for which a URL is created must be kept around in >> > some >> > form for the lifetime of the application." >> > 2. A blob passed to between documents would have its blob.url stop >> > working >> > as soon as the original document got closed. >> > 3. Having a model that makes the url have a determinate lifetime which >> > doesn't expose the web developer to indeterminate behaviors issues like >> > we >> > have discussed above. >> > The current spec has issues #1 and #2. >> > Binding the lifetime of blob.url to blob has issue #3. >> >> Indeed. >> >> I agree with others that have said that exposing GC behavior is a big >> problem. I think especially here where a very natural usage pattern is >> to grab a File object, extract its url, and then drop the reference to >>
Re: Lifetime of Blob URL
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. 2. If blob is sent to a Worker via worker.postMessage(blob), the 'structured clone' mechanism is used, so on the other side of postMessage a new blob object is created, backed by the same data, but having its own unique blob.url string (and separate lifetime). Dmitry On Mon, Jul 26, 2010 at 2:12 PM, Jonas Sicking wrote: > On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: > > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman > > wrote: > >> > >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin > wrote: > >> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman < > adria...@microsoft.com> > >> > wrote: > >> > I read point #5 to be only about surviving the start of a navigation. > As > >> > a > >> > web developer, how can I tell when a load has started for an ? > >> > Isn't > >> > this similarly indeterminate. > >> > > >> > As soon as img.src is set. > >> > > >> > "the spec could mention that the resource pointed by blob URL should > be > >> > loaded successfully as long as the blob URL is valid at the time when > >> > the > >> > resource is starting to load." > >> > > >> > Should apply to xhr (after send is called), img, and navigation. > >> > > >> > Right, it seems reasonable to say that ownership of the resource > >> > referenced > >> > by a Blob can be shared by a XHR, Image, or navigation once it is told > >> > to > >> > start loading the resource. > >> > > >> > -Darin > >> > >> It sounds like you are saying the following is guaranteed to work: > >> > >> img.src = blob.url; > >> window.revokeBlobUrl(blob); > >> return; > >> > >> If that is the case then the user agent is already making the guarantees > >> I was talking about and so I still think having the lifetime mapped to > the > >> blob > >> not the document is better. This means that in the general case I don't > >> have > >> to worry about lifetime management. > > > > Mapping lifetime to the blob exposes when the blob gets garbage collected > > which is a very indeterminate point in time (and is very browser version > > dependent -- it will set you up for compatibility issues when you update > > your javascript engine -- and there are also the cross browser issues of > > course). > > Specifically, a blob could go "out of scope" (to use your earlier phrase) > > and then one could do img.src = blobUrl (the url that was exposed from > the > > blob but not using the blob object). This will work sometimes but not > others > > (depending on whether garbage collection collected the blob). > > This is much more indeterminate than the current spec which maps the > > blob.url lifetime to the lifetime of the document where the blob was > > created. > > When thinking about blob.url lifetime, there are several problems to > solve: > > 1. "An AJAX style web application may never navigate the document and > this > > means that every blob for which a URL is created must be kept around in > some > > form for the lifetime of the application." > > 2. A blob passed to between documents would have its blob.url stop > working > > as soon as the original document got closed. > > 3. Having a model that makes the url have a determinate lifetime which > > doesn't expose the web developer to indeterminate behaviors issues like > we > > have discussed above. > > The current spec has issues #1 and #2. > > Binding the lifetime of blob.url to blob has issue #3. > > Indeed. > > I agree with others that have said that exposing GC behavior is a big > problem. I think especially here where a very natural usage pattern is > to grab a File object, extract its url, and then drop the reference to > the File object on the floor. > > And I don't think specifying how GC is supposed to work is a workable > solution. I doubt that any browser vendor will be willing to lock down > their GC to that degree. GC implementations is a very active area of > experimentation and has been for many many years. I see no reason to > think that we'd be able to come up with a GC algorithm that wouldn't > be obsolete very soon. > > However I also don't think #3 above is a huge problem. You can always > flush a blob to disk, meaning that all that is leaked is an entry in a > url->filename hash table. No actual data needs to be kept in memory. > It's definitely still a problem, but I figured it's worth pointing > out. > > Given that, I see no other significantly different solution than what > is in the spec ri
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote: > On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman > wrote: >> >> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: >> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote: >> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman >> > wrote: >> > I read point #5 to be only about surviving the start of a navigation. As >> > a >> > web developer, how can I tell when a load has started for an ? >> > Isn't >> > this similarly indeterminate. >> > >> > As soon as img.src is set. >> > >> > "the spec could mention that the resource pointed by blob URL should be >> > loaded successfully as long as the blob URL is valid at the time when >> > the >> > resource is starting to load." >> > >> > Should apply to xhr (after send is called), img, and navigation. >> > >> > Right, it seems reasonable to say that ownership of the resource >> > referenced >> > by a Blob can be shared by a XHR, Image, or navigation once it is told >> > to >> > start loading the resource. >> > >> > -Darin >> >> It sounds like you are saying the following is guaranteed to work: >> >> img.src = blob.url; >> window.revokeBlobUrl(blob); >> return; >> >> If that is the case then the user agent is already making the guarantees >> I was talking about and so I still think having the lifetime mapped to the >> blob >> not the document is better. This means that in the general case I don't >> have >> to worry about lifetime management. > > Mapping lifetime to the blob exposes when the blob gets garbage collected > which is a very indeterminate point in time (and is very browser version > dependent -- it will set you up for compatibility issues when you update > your javascript engine -- and there are also the cross browser issues of > course). > Specifically, a blob could go "out of scope" (to use your earlier phrase) > and then one could do img.src = blobUrl (the url that was exposed from the > blob but not using the blob object). This will work sometimes but not others > (depending on whether garbage collection collected the blob). > This is much more indeterminate than the current spec which maps the > blob.url lifetime to the lifetime of the document where the blob was > created. > When thinking about blob.url lifetime, there are several problems to solve: > 1. "An AJAX style web application may never navigate the document and this > means that every blob for which a URL is created must be kept around in some > form for the lifetime of the application." > 2. A blob passed to between documents would have its blob.url stop working > as soon as the original document got closed. > 3. Having a model that makes the url have a determinate lifetime which > doesn't expose the web developer to indeterminate behaviors issues like we > have discussed above. > The current spec has issues #1 and #2. > Binding the lifetime of blob.url to blob has issue #3. Indeed. I agree with others that have said that exposing GC behavior is a big problem. I think especially here where a very natural usage pattern is to grab a File object, extract its url, and then drop the reference to the File object on the floor. And I don't think specifying how GC is supposed to work is a workable solution. I doubt that any browser vendor will be willing to lock down their GC to that degree. GC implementations is a very active area of experimentation and has been for many many years. I see no reason to think that we'd be able to come up with a GC algorithm that wouldn't be obsolete very soon. However I also don't think #3 above is a huge problem. You can always flush a blob to disk, meaning that all that is leaked is an entry in a url->filename hash table. No actual data needs to be kept in memory. It's definitely still a problem, but I figured it's worth pointing out. Given that, I see no other significantly different solution than what is in the spec right now. Though there are definitely some problems that we should fix: 1. Add a function for "destroying" a url reference seems like a good idea. 2. #2 above can be specced away. You simply need to specify that any context that calls blob.url extends the lifetime such that the url isn't automatically destroyed until all contexts that requested it are destroyed. 3. We should define that worker scopes can also extract blob urls. However this leaves deciding on what syntax to use for creating and destroying URLs. The current method of obtaining a url is: x = myfile.url; we could simply add myfile.killUrl(); which kills the url that was previously returned from the file. However this requires that people hold on to the Blob object and so seems like a suboptimal solution. We could also do x = myfile.url; we could simply add window.destroyBlobUrl(x); However this keeps the creator and destructor functions far from each other, which IMHO isn't very nice. It has also been suggested that we change the syntax for obtaining urls to: x = window.createBlobUrl(myfile); and window.destroyBlobU
Re: Lifetime of Blob URL
Tying a 'lifetime' of a string url to a blob which is not even needed at the
point of use seems to be creating a mechanism that doesn't generally work:
function getImageUrl() {
var a_blob = ... load a blob in some way, perhaps via XHR
return a_blob.url;
}
... // sometime during initialization
var imageUrl = getImageUrl();
... // sometime later
anImage.src = imageUrl;
This may work all the time on the developer's computer and fail all the time
(or sometimes) in the field. It may be very frustrating. Tying
lifetime explicitly to the Window (url dies when window closes or revoke()
is called) does not fix all the issues but makes the mechanism less likely
to shoot the user in the foot by making it more explicit.
Dmitry
On Tue, Jul 13, 2010 at 7:37 AM, David Levin wrote:
>
>
> On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman wrote:
>
>> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
>> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote:
>> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman > >
>> > wrote:
>> > I read point #5 to be only about surviving the start of a navigation. As
>> a
>> > web developer, how can I tell when a load has started for an ?
>> Isn't
>> > this similarly indeterminate.
>> >
>> > As soon as img.src is set.
>> >
>> > "the spec could mention that the resource pointed by blob URL should be
>> > loaded successfully as long as the blob URL is valid at the time when
>> the
>> > resource is starting to load."
>> >
>> > Should apply to xhr (after send is called), img, and navigation.
>> >
>> > Right, it seems reasonable to say that ownership of the resource
>> referenced
>> > by a Blob can be shared by a XHR, Image, or navigation once it is told
>> to
>> > start loading the resource.
>> >
>> > -Darin
>>
>> It sounds like you are saying the following is guaranteed to work:
>>
>> img.src = blob.url;
>> window.revokeBlobUrl(blob);
>> return;
>>
>> If that is the case then the user agent is already making the guarantees
>> I was talking about and so I still think having the lifetime mapped to the
>> blob
>> not the document is better. This means that in the general case I don't
>> have
>> to worry about lifetime management.
>>
>
> Mapping lifetime to the blob exposes when the blob gets garbage collected
> which is a very indeterminate point in time (and is very browser version
> dependent -- it will set you up for compatibility issues when you update
> your javascript engine -- and there are also the cross browser issues of
> course).
>
> Specifically, a blob could go "out of scope" (to use your earlier phrase)
> and then one could do img.src = blobUrl (the url that was exposed from the
> blob but not using the blob object). This will work sometimes but not others
> (depending on whether garbage collection collected the blob).
>
> This is much more indeterminate than the current spec which maps the
> blob.url lifetime to the lifetime of the document where the blob was
> created.
>
> When thinking about blob.url lifetime, there are several problems to solve:
> 1. "An AJAX style web application may never navigate the document and this
> means that every blob for which a URL is created must be kept around in
> some form for the lifetime of the application."
> 2. A blob passed to between documents would have its blob.url stop working
> as soon as the original document got closed.
> 3. Having a model that makes the url have a determinate lifetime which
> doesn't expose the web developer to indeterminate behaviors issues like we
> have discussed above.
>
> The current spec has issues #1 and #2.
> Binding the lifetime of blob.url to blob has issue #3.
>
> dave
>
>
>
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman wrote: > On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > > On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote: > > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman > > wrote: > > I read point #5 to be only about surviving the start of a navigation. As > a > > web developer, how can I tell when a load has started for an ? Isn't > > this similarly indeterminate. > > > > As soon as img.src is set. > > > > "the spec could mention that the resource pointed by blob URL should be > > loaded successfully as long as the blob URL is valid at the time when the > > resource is starting to load." > > > > Should apply to xhr (after send is called), img, and navigation. > > > > Right, it seems reasonable to say that ownership of the resource > referenced > > by a Blob can be shared by a XHR, Image, or navigation once it is told to > > start loading the resource. > > > > -Darin > > It sounds like you are saying the following is guaranteed to work: > > img.src = blob.url; > window.revokeBlobUrl(blob); > return; > > If that is the case then the user agent is already making the guarantees > I was talking about and so I still think having the lifetime mapped to the > blob > not the document is better. This means that in the general case I don't > have > to worry about lifetime management. > Mapping lifetime to the blob exposes when the blob gets garbage collected which is a very indeterminate point in time (and is very browser version dependent -- it will set you up for compatibility issues when you update your javascript engine -- and there are also the cross browser issues of course). Specifically, a blob could go "out of scope" (to use your earlier phrase) and then one could do img.src = blobUrl (the url that was exposed from the blob but not using the blob object). This will work sometimes but not others (depending on whether garbage collection collected the blob). This is much more indeterminate than the current spec which maps the blob.url lifetime to the lifetime of the document where the blob was created. When thinking about blob.url lifetime, there are several problems to solve: 1. "An AJAX style web application may never navigate the document and this means that every blob for which a URL is created must be kept around in some form for the lifetime of the application." 2. A blob passed to between documents would have its blob.url stop working as soon as the original document got closed. 3. Having a model that makes the url have a determinate lifetime which doesn't expose the web developer to indeterminate behaviors issues like we have discussed above. The current spec has issues #1 and #2. Binding the lifetime of blob.url to blob has issue #3. dave
RE: Lifetime of Blob URL
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: > On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote: > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman > wrote: > I read point #5 to be only about surviving the start of a navigation. As a > web developer, how can I tell when a load has started for an ? Isn't > this similarly indeterminate. > > As soon as img.src is set. > > "the spec could mention that the resource pointed by blob URL should be > loaded successfully as long as the blob URL is valid at the time when the > resource is starting to load." > > Should apply to xhr (after send is called), img, and navigation. > > Right, it seems reasonable to say that ownership of the resource referenced > by a Blob can be shared by a XHR, Image, or navigation once it is told to > start loading the resource. > > -Darin It sounds like you are saying the following is guaranteed to work: img.src = blob.url; window.revokeBlobUrl(blob); return; If that is the case then the user agent is already making the guarantees I was talking about and so I still think having the lifetime mapped to the blob not the document is better. This means that in the general case I don't have to worry about lifetime management. Adrian.
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 12:48 AM, Anne van Kesteren wrote: > On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher > wrote: > >> Right, it seems reasonable to say that ownership of the resource >> referenced by a Blob can be shared by a XHR, Image, or navigation once it is >> told to >> start loading the resource. >> > > Note that unless we make changes (separate thread please) to XMLHttpRequest > this will not work. It is a cross-origin URL which cannot work with CORS. > It seems the origin for blob.url is defined to make it not cross-origin: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlob and here http://dev.w3.org/2006/webapi/FileAPI/#url it mentions using the url for xhr again. dave > > -- > Anne van Kesteren > http://annevankesteren.nl/ >
Re: Lifetime of Blob URL
On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher wrote: Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. Note that unless we make changes (separate thread please) to XMLHttpRequest this will not work. It is a cross-origin URL which cannot work with CORS. -- Anne van Kesteren http://annevankesteren.nl/
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote: > > > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman wrote: > >> On Monday, July 12, 2010 9:32 AM, David Levin wrote: >> > On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman > > >> > wrote: >> > The behaviour would have to be explicitly specified and not left to >> depend on >> > indeterminate browser implementations. >> > >> > Yes. Unfortunately, another way of saying that "the url lives as long as >> the >> > Blob lives" is "the url lives until the Blob is garbage collected". This >> > exposes a very indeterminate behavior. >> >> Exactly. So what I'm saying is the spec needs to say more than just that. >> It needs to make further guarantees. >> >> > >> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html >> > See point #5 basically once a load has started for a url, that >> > load should succeed and revoke may be called. >> >> I read point #5 to be only about surviving the start of a navigation. As a >> web developer, how can I tell when a load has started for an ? Isn't >> this similarly indeterminate. >> > > As soon as img.src is set. > > > "the spec could mention that the resource pointed by blob URL should be > loaded successfully as long as the blob URL is valid at the time when the > resource is starting to load." > > > Should apply to xhr (after send is called), img, and navigation. > > > Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. -Darin > >> Regards, >> >> Adrian. >> > >
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman wrote: > On Monday, July 12, 2010 9:32 AM, David Levin wrote: > > On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman > > wrote: > > The behaviour would have to be explicitly specified and not left to > depend on > > indeterminate browser implementations. > > > > Yes. Unfortunately, another way of saying that "the url lives as long as > the > > Blob lives" is "the url lives until the Blob is garbage collected". This > > exposes a very indeterminate behavior. > > Exactly. So what I'm saying is the spec needs to say more than just that. > It needs to make further guarantees. > > > http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html > > See point #5 basically once a load has started for a url, that > > load should succeed and revoke may be called. > > I read point #5 to be only about surviving the start of a navigation. As a > web developer, how can I tell when a load has started for an ? Isn't > this similarly indeterminate. > As soon as img.src is set. "the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load." Should apply to xhr (after send is called), img, and navigation. > Regards, > > Adrian. >
RE: Lifetime of Blob URL
On Monday, July 12, 2010 9:32 AM, David Levin wrote: > On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman > wrote: > The behaviour would have to be explicitly specified and not left to depend on > indeterminate browser implementations. > > Yes. Unfortunately, another way of saying that "the url lives as long as the > Blob lives" is "the url lives until the Blob is garbage collected". This > exposes a very indeterminate behavior. Exactly. So what I'm saying is the spec needs to say more than just that. It needs to make further guarantees. > http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html > See point #5 basically once a load has started for a url, that > load should succeed and revoke may be called. I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an ? Isn't this similarly indeterminate. Regards, Adrian.
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman wrote: > On Monday, July 12, 2010 8:24 AM, David Levin wrote: > > On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman > > wrote: > > > Making the blob url identical to the lifetime of the blob itself would > > > expose when garbage collection takes place and in general could lead to > > > easy to make mistakes in which the developer had something that work > > > mostly but not always -- your situation below is just one of them. > > > > > > Check out the Jian Li's alternate proposal (see his response to "Re: > > > [File API] Recent Updates To Specification + Co-Editor" on July 1, I > > > think) that addresses this in a way that addresses your concerns and > the > > > gc issue as well. > > The problem with an explicit revoke call is that people need to know to > > call it, need to actually call it, and need to know when it is > appropriate > > to call. Many of the same timing issues that cause potential problems > with > > GC also make it hard for web developers to know when to call revoke. > > > > When GC occurs is indeterminate and would vary greatly between browsers. > > Developing features which exposes the gc behavior would lead developers > > into accidentally relying on browser specific behaviors (which may even > break > > for the same browser during upgrades). > > The behaviour would have to be explicitly specified and not left to depend > on > indeterminate browser implementations. > Yes. Unfortunately, another way of saying that "the url lives as long as the Blob lives" is "the url lives until the Blob is garbage collected". This exposes a very indeterminate behavior. > > > As I read Jian's proposal, there is a create call (blob.url would go > away), > > so there would clearly be a revoke (or destroy call). > > > > With respect to timing issues, the behavior of revoke with respect to > load is > > clearly defined in his proposal which result in very deterministic > behavior. > > My apologies. I think I missed this part - please can you provide a link to > the > full proposal? At what point after I assign the src of an element can > I > call revoke? Can I do it immediately after the assignment or do I have to > have > an onload and onerror handler for every element that uses it? With XHR do I > have > to wait for readyState 4 or can I call revoke earlier in the process? http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/.html See point #5 basically once a load has started for a url, that load should succeed and revoke may be called. > Is there > reference counting so that if I call create twice I have to call revoke > twice? > I don't think this has been specified, but a simple proposal would be that each create call would result in a unique url. > > Thanks, > > Adrian. >
RE: Lifetime of Blob URL
On Monday, July 12, 2010 8:24 AM, David Levin wrote: > On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman > wrote: > > Making the blob url identical to the lifetime of the blob itself would > > expose when garbage collection takes place and in general could lead to > > easy to make mistakes in which the developer had something that work > > mostly but not always -- your situation below is just one of them. > > > > Check out the Jian Li's alternate proposal (see his response to "Re: > > [File API] Recent Updates To Specification + Co-Editor" on July 1, I > > think) that addresses this in a way that addresses your concerns and the > > gc issue as well. > The problem with an explicit revoke call is that people need to know to > call it, need to actually call it, and need to know when it is appropriate > to call. Many of the same timing issues that cause potential problems with > GC also make it hard for web developers to know when to call revoke. > > When GC occurs is indeterminate and would vary greatly between browsers. > Developing features which exposes the gc behavior would lead developers > into accidentally relying on browser specific behaviors (which may even break > for the same browser during upgrades). The behaviour would have to be explicitly specified and not left to depend on indeterminate browser implementations. > As I read Jian's proposal, there is a create call (blob.url would go away), > so there would clearly be a revoke (or destroy call). > > With respect to timing issues, the behavior of revoke with respect to load is > clearly defined in his proposal which result in very deterministic behavior. My apologies. I think I missed this part - please can you provide a link to the full proposal? At what point after I assign the src of an element can I call revoke? Can I do it immediately after the assignment or do I have to have an onload and onerror handler for every element that uses it? With XHR do I have to wait for readyState 4 or can I call revoke earlier in the process? Is there reference counting so that if I call create twice I have to call revoke twice? Thanks, Adrian.
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman wrote: > > > Making the blob url identical to the lifetime of the blob itself would > > expose when garbage collection takes place and in general could lead to > > easy to make mistakes in which the developer had something that work > > mostly but not always -- your situation below is just one of them. > > > > Check out the Jian Li's alternate proposal (see his response to "Re: > > [File API] Recent Updates To Specification + Co-Editor" on July 1, I > > think) that addresses this in a way that addresses your concerns and the > > gc issue as well. > > The problem with an explicit revoke call is that people need to know to > call it, need to actually call it, and need to know when it is appropriate > to call. Many of the same timing issues that cause potential problems with > GC also make it hard for web developers to know when to call revoke. When GC occurs is indeterminate and would vary greatly between browsers. Developing features which exposes the gc behavior would lead developers into accidentally relying on browser specific behaviors (which may even break for the same browser during upgrades). As I read Jian's proposal, there is a create call (blob.url would go away), so there would clearly be a revoke (or destroy call). With respect to timing issues, the behavior of revoke with respect to load is clearly defined in his proposal which result in very deterministic behavior. dave
RE: Lifetime of Blob URL
On Sunday, July 11, 2010 10:40 PM, David Levin wrote: > On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman > wrote: > Hi Arun, I think the updated URL section reflects a good compromise. We > might want to call out explicitly that "opaque string" should not include > recognisable metadata to avoid scripts from trying to parse the URL. User > Agents that wish to include data such as origin should do so by encoding > it in an opaque manner. > > Specifying the format of contents of the url is simply an > overspecification. Saying "User Agents that wish to include data such as > origin should do so by encoding it in an opaque manner." is ambiguious. > As soon as anyone publishes the format (which would be trivial to do > given chromium's open source), the format would no longer be opaque. Of course and I wasn't writing spec text merely raising the idea. Feel free as always to propose some text. I think there's a clear difference between going to find the chromium source and figuring out how to decode the origin and seeing origin=blah in the string. > I have one other concern about the lifetime of the blob URL [1]. The spec > currently says that blob: URLs should have the lifetime of the Document. > I think this is too long. An AJAX style web application may never > navigate > the document and this means that every blob for which a URL is created > must be kept around in some form for the lifetime of the application. > > In our discussions on this topic at Microsoft we've assumed that the > lifetime for a blob URL will be the same as the lifetime of the blob > itself. > > Making the blob url identical to the lifetime of the blob itself would > expose when garbage collection takes place and in general could lead to > easy to make mistakes in which the developer had something that work > mostly but not always -- your situation below is just one of them. > > Check out the Jian Li's alternate proposal (see his response to "Re: > [File API] Recent Updates To Specification + Co-Editor" on July 1, I > think) that addresses this in a way that addresses your concerns and the > gc issue as well. The problem with an explicit revoke call is that people need to know to call it, need to actually call it, and need to know when it is appropriate to call. Many of the same timing issues that cause potential problems with GC also make it hard for web developers to know when to call revoke. > This does create something of a race condition. If I have a blob > representing an image where I set the src of an element and then > let the blob go out of scope might it be collected before the loads > the resource? We think we'll have to include some mechanism to ensure > that > the blob and URL doesn't get collected before pending network requests > have been made. > > This does impose an additional burden on the web developer: if they later > want to copy the source URL from one to another then this will only > work if they also kept the blob in scope somewhere. > > What do you think? > > Cheers, > > Adrian. > > [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime >
Re: Lifetime of Blob URL
On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman wrote: > On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote: > > On 6/23/10 9:50 AM, Jian Li wrote: > > I think encoding the security origin in the URL allows the UAs to do > > the security origin check in place, without routing through other > > authority to get the origin information that might cause the check > > taking long time to finish. > > > > If we worry about showing the double schemes in the URL, we can > > transform the origin encoded in the URL by using base64 or other > > escaping algorithm. > > > > Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url > > allows you to do that, without obliging other UAs to do that. Some > > UAs may elect to use "smart caching" to accomplish the same kinds of > > things, without tagging the URL with origin information. Others may > > see benefit in origin-tagging. > > > > I've reconsidered trying to architect a scheme that allows all use-case > > scenarios for blob: URIs. > > Hi Arun, I think the updated URL section reflects a good compromise. We > might want to call out explicitly that "opaque string" should not include > recognisable metadata to avoid scripts from trying to parse the URL. User > Agents that wish to include data such as origin should do so by encoding > it in an opaque manner. > Specifying the format of contents of the url is simply an overspecification. Saying "User Agents that wish to include data such as origin should do so by encoding it in an opaque manner." is ambiguious. As soon as anyone publishes the format (which would be trivial to do given chromium's open source), the format would no longer be opaque. > I have one other concern about the lifetime of the blob URL [1]. The spec > currently says that blob: URLs should have the lifetime of the Document. > I think this is too long. An AJAX style web application may never navigate > the document and this means that every blob for which a URL is created > must be kept around in some form for the lifetime of the application. > > In our discussions on this topic at Microsoft we've assumed that the > lifetime for a blob URL will be the same as the lifetime of the blob > itself. Making the blob url identical to the lifetime of the blob itself would expose when garbage collection takes place and in general could lead to easy to make mistakes in which the developer had something that work mostly but not always -- your situation below is just one of them. Check out the Jian Li's alternate proposal (see his response to "Re: [File API] Recent Updates To Specification + Co-Editor" on July 1, I think) that addresses this in a way that addresses your concerns and the gc issue as well. > This does create something of a race condition. If I have a blob > representing an image where I set the src of an element and then > let the blob go out of scope might it be collected before the loads > the resource? We think we'll have to include some mechanism to ensure that > the blob and URL doesn't get collected before pending network requests > have been made. > > This does impose an additional burden on the web developer: if they later > want to copy the source URL from one to another then this will only > work if they also kept the blob in scope somewhere. > > What do you think? > > Cheers, > > Adrian. > > [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime > > >
Lifetime of Blob URL
On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote: > On 6/23/10 9:50 AM, Jian Li wrote: > I think encoding the security origin in the URL allows the UAs to do > the security origin check in place, without routing through other > authority to get the origin information that might cause the check > taking long time to finish. > > If we worry about showing the double schemes in the URL, we can > transform the origin encoded in the URL by using base64 or other > escaping algorithm. > > Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url > allows you to do that, without obliging other UAs to do that. Some > UAs may elect to use "smart caching" to accomplish the same kinds of > things, without tagging the URL with origin information. Others may > see benefit in origin-tagging. > > I've reconsidered trying to architect a scheme that allows all use-case > scenarios for blob: URIs. Hi Arun, I think the updated URL section reflects a good compromise. We might want to call out explicitly that "opaque string" should not include recognisable metadata to avoid scripts from trying to parse the URL. User Agents that wish to include data such as origin should do so by encoding it in an opaque manner. I have one other concern about the lifetime of the blob URL [1]. The spec currently says that blob: URLs should have the lifetime of the Document. I think this is too long. An AJAX style web application may never navigate the document and this means that every blob for which a URL is created must be kept around in some form for the lifetime of the application. In our discussions on this topic at Microsoft we've assumed that the lifetime for a blob URL will be the same as the lifetime of the blob itself. This does create something of a race condition. If I have a blob representing an image where I set the src of an element and then let the blob go out of scope might it be collected before the loads the resource? We think we'll have to include some mechanism to ensure that the blob and URL doesn't get collected before pending network requests have been made. This does impose an additional burden on the web developer: if they later want to copy the source URL from one to another then this will only work if they also kept the blob in scope somewhere. What do you think? Cheers, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
