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
<[email protected]> 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?
