[whatwg] File API Streaming Blobs

Anne van Kesteren annevk at opera.com
Wed Jan 26 02:41:29 PST 2011

On Tue, 25 Jan 2011 19:05:32 +0100, David Flanagan  
<david at davidflanagan.com> wrote:
> I don't see the point of that, if all it does is save one call to  
> URL.createObjectURL() (and also one call to revokeObjectURL())?

The point is that authors will not have to do any cleanup. Objects get  
cleaned up automatically. So besides being easier it is also safer.

> Adam's use case--to be able to download, play and cache audio data at  
> the same time--seems like a pretty compelling one.  I think this is  
> fundamentally an issue with the Blob API, not the URL API.  Blobs just  
> seem like they ought to stream.  When you get a blob in the onprogress  
> handler of an XHR2, you ought to be able to fire up a FileReader on it  
> and have it automatically read from the blob as the XHR2 writes to the  
> blob.  But currently (I think) you have to slice the blob to get only  
> the new bytes and start a new FileReader each time onprogress is called.  
>   (Or wait for onload, of course.)

You have to wait for onload currently.

> Similarly, when you get your first onprogress event for a Blob download,  
> you ought to be able to create a URL for that Blob that remains valid  
> while the download is in progress.  So you can use that url with an  
> audio element, for example.

Yeah, I do not quite see why the URL cannot remain valid.

> P.S. This is probably the wrong list for this discussion, isn't it?

public-webapps at w3.org is preferable, but it does not matter much.

Anne van Kesteren

More information about the whatwg mailing list