- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 21 Jan 2011 17:31:30 -0500
On Fri, Jan 21, 2011 at 4:59 PM, Roger H?gensen <rescator at emsai.net> wrote: > Hmm! And I guess it's very difficult to create a abstract in/out interface > that can handle any protocol/stream. > Although an abstract in/out would be ideal as that would let new protocols > to be supported without needing to rewrite anything at the higher level. I wouldn't expect it to try to pretend it's a network protocol any more than file:// URLs. Another complexity: what happens if you create a URL for a streaming blob, and then it's opened more than once? That might happen even if you only use the URL in one place. It would need to be a pull API, not a push API, with a callback to request blocks of data asynchronously. Here's an example of how that could work. Notice that the response to b.requestData is async: the response callbacks can be called after requestData returns. This implicitly handles cases where the URL is opened multiple times, allows seeking and caller bandwidth throttling. (This is just a rough sketch, of course; there'd need to be mechanisms for EOF, for providing the total file size if known so download progress bars work, and so on.) var b = new StreamingBlob(); b.requestData = function(request, response) { var blob = dataBlob.slice(request.start, request.bytes); var reader = new FileReader(); reader.onload = function(e) { response.success(reader.result); } reader.onerror = function(e) { response.error(...); } reader.readAsBinaryString(blob); } video.src = createObjectURL(b); -- Glenn Maynard
Received on Friday, 21 January 2011 14:31:30 UTC