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 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
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,
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
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
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
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
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
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
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: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.
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,
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().
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
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:
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
34 matches
Mail list logo
