- 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