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 ann...@opera.comwrote:
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
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
On Mon, Aug 30, 2010 at 11:14 AM, Jian Li jia...@chromium.org wrote: On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.comwrote: 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 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?) 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 1:08 PM, Jonas Sicking jo...@sicking.cc 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. 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 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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
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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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:14 PM, Dmitry Titov dim...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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
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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov dim...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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 jia...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov dim...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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
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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:23 PM, Jian Li jia...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov dim...@chromium.org 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 jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc 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 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! -- Anne van Kesteren http://annevankesteren.nl/
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 er...@google.com wrote: I agree with Dmitry: window.createBlobUrl() makes it clearer. Querying blob.url shouldn't have side effects. As Jonas points out, we should keep the creation and destruction methods near each other, so window.destroyBlobUrl() would be the opposite function. As for getBlobUrl vs. createBlobUrl: the latter sounds like it returns a new URL each time. The former is less explicit. If we're returning a unique URL per call, then create is clearly better. Are we requiring that each call to xxxBlobUrl have a matched destroyBlobUrl, even if we're returning the same URL? I think BlobError and BlobException make a bit more sense, but I'm not too adamant about it. On Sat, Aug 21, 2010 at 1:00 PM, Jian Li jia...@google.com wrote: I do not see any more discussions on blob URL API in recent days. Any more thoughts or conclusion? In addition, do we want to rename FileError and File Exception to BlobError and BlobException to match with BlobReader naming, or rather keep them intact? On Mon, Aug 2, 2010 at 3:22 PM, Dmitry Titov dim...@chromium.org wrote: It feels developers will make less errors with window.getBlobUrl(blob) kind of API, because, unlike blob.url, it doesn't violate pretty common programming assumptions (like querying a property of the same object should return the same value if nothing was done to the object, or that value of property should not depend on what is a global object in the context of the query if the blob is the same). The spec language describing why and when blob.url returns different values with different lifetimes would be a bit hairy... Agree though that functionally they are the same. On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman micha...@google.com wrote: On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov 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 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.
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 jia...@google.com wrote: I do not see any more discussions on blob URL API in recent days. Any more thoughts or conclusion? In addition, do we want to rename FileError and File Exception to BlobError and BlobException to match with BlobReader naming, or rather keep them intact? On Mon, Aug 2, 2010 at 3:22 PM, Dmitry Titov dim...@chromium.org wrote: It feels developers will make less errors with window.getBlobUrl(blob) kind of API, because, unlike blob.url, it doesn't violate pretty common programming assumptions (like querying a property of the same object should return the same value if nothing was done to the object, or that value of property should not depend on what is a global object in the context of the query if the blob is the same). The spec language describing why and when blob.url returns different values with different lifetimes would be a bit hairy... Agree though that functionally they are the same. On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman micha...@google.com wrote: On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov 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 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 dim...@chromium.org wrote: It feels developers will make less errors with window.getBlobUrl(blob) kind of API, because, unlike blob.url, it doesn't violate pretty common programming assumptions (like querying a property of the same object should return the same value if nothing was done to the object, or that value of property should not depend on what is a global object in the context of the query if the blob is the same). The spec language describing why and when blob.url returns different values with different lifetimes would be a bit hairy... Agree though that functionally they are the same. On Mon, Aug 2, 2010 at 3:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 2:19 PM, Michael Nordman micha...@google.com wrote: On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov 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 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 Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman micha...@google.com wrote: On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov 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 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 jo...@sicking.cc wrote: Sorry about the slow response. I'm currently at blackhat, so my internet connectivity is somewhat... unreliable, so generally having to try to stay off the webs :) On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov 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. 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 jo...@sicking.cc wrote: On Tue, Jul 13, 2010 at 7:37 AM, David Levin le...@google.com 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 le...@google.com 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 img? 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
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 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. 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 jo...@sicking.cc wrote: On Tue, Jul 13, 2010 at 7:37 AM, David Levin le...@google.com 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 le...@google.com 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 img? 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
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 jo...@sicking.cc wrote: On Tue, Jul 13, 2010 at 7:37 AM, David Levin le...@google.com 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 le...@google.com 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 img? 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
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 7:37 AM, David Levin le...@google.com 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 le...@google.com 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 img? 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.destroyBlobUrl(x); however the myfile.url syntax feels really nice and
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 le...@google.com wrote:
On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman adria...@microsoft.comwrote:
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com 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 img?
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 Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher da...@chromium.org 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 Tue, Jul 13, 2010 at 12:48 AM, Anne van Kesteren ann...@opera.comwrote: On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher da...@chromium.org 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 Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com 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 img? 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 6:50 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com 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 img? 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 Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.comwrote: 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 Monday, July 12, 2010 8:24 AM, David Levin wrote: On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com 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 img 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 8:39 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 8:24 AM, David Levin wrote: On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com 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 img 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 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com 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 img? Isn't this similarly indeterminate. Regards, Adrian.
Re: Lifetime of Blob URL
On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com 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 img? 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 Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote: On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 9:32 AM, David Levin wrote: On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com 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 img? 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.
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 img element and then let the blob go out of scope might it be collected before the img 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 img 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 adria...@microsoft.comwrote: 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 img element and then let the blob go out of scope might it be collected before the img 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 img 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
