- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 27 Apr 2011 02:14:34 -0700
On Wed, Apr 13, 2011 at 11:42 PM, Kyle Huey <me at kylehuey.com> wrote: > It doesn't necessarily imply that the encoding is synchronous. > > The problem here is that Blob.size is broken.? The point of the File API is > to do reads asynchronously without blocking the main thread on something > slow.? This is why the only way to get at a Blob's contents is through > something like FileReader which is asynchronous and event driven.? Blob.size > goes totally against all of this.? I wonder if it's possible to remove size > entirely?? Jonas?? It's been shipped in Firefox since 3.5 though, and Chrome > since some version from quite a while ago, so I fear it's here to stay. Yeah, I think the current Blob and File interfaces are here to stay. Not just because they have shipped, but because in all other situations access to the File/Blob object is asynchronous, and so providing synchronous access to metadata makes a lot of sense. However, we could possibly come up with something like a UnsizedBlob interface. We could possibly even make that a base-class of the normal Blob interface. However it would mean introducing a lot of complexity. All functions that currently take Blob should be changed to take UnsizedBlob. And how would something like BlobBuilder work? Would it return an UnsizedBlob or a Blob? Unless we can come up with other APIs where a UnsizedBlob would make sense, I'm tempted to say that we should use an asynchronous callback here. / Jonas
Received on Wednesday, 27 April 2011 02:14:34 UTC