- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 24 Jan 2011 13:24:22 +0100
(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. > 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? -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 24 January 2011 04:24:22 UTC