[whatwg] File API Streaming Blobs

[David Flanagan]

On 01/24/2011 04:24 AM, Anne van Kesteren wrote:
> (I removed the Chromium related list as I am not subscribed there.)
>
> On Fri, 21 Jan 2011 21:35:53 +0100, Adam Malcontenti-Wilson
> <adman.com at gmail.com> wrote:
>> XHR2 is one part of the APIs required for my use case as that is the
>> easiest way to download for example a music file. However, while
>> downloading, there's no way to pipe the download(ing) blob to the
>> HTML5 Audio element as to play Audio it requires an object URL, and an
>> object URL can (currently) only point to a static Blob, as well as the
>> fact that a Blob cannot be appended. This would be important for
>> listening streaming audio that needs to be processed in JavaScript or
>> cached to persistant storage using the Filesystem APIs without having
>> to wait for the entire file to be downloaded into an ArrayBuffer or
>> Blob.
>
> There is a plan of allowing direct assigning to IDL attributes besides
> creating URLs.
>
> I.e. being able to do:
>
> audio.src = blob
>
> (The src content attribute would then be something like "about:objecturl".)
>
> I am not sure if that API should work differently from creating URLs and
> assigning those, but we could consider it.

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())?

In any case, making this behave differently than the URL API seems like 
a bad idea.

>
>> My suggestion was for another alternative version of Blob and/or
>> createObjectUrl that mimicks how a HTTP request can be parsed and (in
>> the case of audio or video) start playing before it has finished
>> downloading (e.g. got to the content-length or had a connection close)
>> by pushing content when it is appended to the blob and then the
>> "virtual connection" can be closed when the Blob has finished being
>> built by calling a close() function. I've also thought of other
>> alternatives, but I'd make sure that there isn't already a way to do
>> this with the current (specified) APIs, and I think this has the most
>> other use cases as any data that takes a while to process can be
>> streamed to the user or other parts of the browser.
>
> Is there actually a good reason for the URL API to have behave in this way?
>

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.)

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.

Also: BlobBuilder seems to me as if it ought to be a streaming API.  It 
feels like it ought to work like this:

    var bb = new BlobBuilder();
    var b1 = bb.getBlob();
    var u1 = URL.createObjectURL(b1);
    bb.append("hello world");
    var b2 = bb.getBlob();
    var u2 = URL.createObjectURL(b2);
    b1 === b2   // They ought to be equal, but they're not
    u1 === u2   // Ought to be equal, but they're not
    bb.close(); // New method: now no more appends are allowed.

	David

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