W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] File API Streaming Blobs

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 21 Jan 2011 17:31:30 -0500
Message-ID: <AANLkTimOxd6CB+n_DJSfXaLXqOVtU=kxAkhihUP_nPBU@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC