On Tue, 25 Jan 2011 19:05:32 +0100, David Flanagan
<[email protected]> 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?
[email protected] is preferable, but it does not matter much.
--
Anne van Kesteren
http://annevankesteren.nl/
