[whatwg] File API Streaming Blobs
arun at mozilla.com
Wed Jun 22 11:54:08 PDT 2011
> Ian, I wish I knew that earlier when I originally posted the idea,
> there was lots of discussion and good ideas but then it suddenly
> dropped of the face of the earth. Essentially I am fowarding this
> suggestion to public-webapps at w3.org on the basis as apparently most
> discussion of File API specs happen there, and would like to know how
> to move forward with this suggestion.
> The original suggestion and following comments are on the whatwg list
> archive, starting with
> Summing up, the problem with the current implementation of Blobs is
> that once a URI has been generated for them, by design changes are no
> longer reflected in the object URL. In a streaming scenario, this is
> not what is needed, rather a long-living Blob that can be appended is
> needed and 'streamed' to other parts of the browser, e.g. the<video>
> or<audio> element.
> The original use case was: make an application which will download
> media files from a server and cache them locally, as well as playing
> them without making the user wait for the entire file to be
> downloaded, converted to a blob, then saved and played, however such
> an API covers many other use cases such as on-the-fly on-device
> decryption of streamed media content (ie live streams either without
> end or static large files that to download completely would be a waste
> when only the first couple of seconds need to be buffered and
> decrypted before playback can begin)
> Some suggestions were to modify or create a new type of Blob, the
> StreamingBlob which can be changed without its object url changing and
> appended to as new data is downloaded or decoded, and using a similar
> process to how large files may start to be decoded/played by a browser
> before they are fully downloaded. Other suggestions suggested using a
> pull API on the Blob so browsers can request for new data
> asynchronously, such as in
> Some problems however that a browser may face is what to do with urls
> which are opened twice, and whether the object url should start from
> the beginning (which would be needed for decoding encrypted, on-demand
> audio) or start from the end (similar to `tail`, for live streaming
> events that need decryption, etc.).
> P.S. Sorry if I've not done this the right way by forwarding like
> this, I'm not usually active on mailing lists.
I actually think moving to a streaming mode for file reads in general is
desirable, but I'm not entirely sure extending Blobs is the way to go
for *that* use case, which honestly is the main use case I'm interested
in. We may improve upon ideas after this API goes to Last Call for
streaming file reads; hopefully we'll do a better job than other
currently specified live "in memory" and represent "in memory" File
objects as well. A change to the underlying file isn't captured in the
Blob snapshot; moreover, if the file moves or is no longer present at
time of read, an error event is fired while processing a read operation.
The object URL may be dereferenced, but will result in a 404.
The Streaming API explored by WHATWG uses the Object URL scheme for
videoconferencing use cases , and so the scheme itself is suitable
for "resources" that are more dynamic than memory-resident Blob objects.
Segment-plays/segment dereferencing in general can be handled through
media fragments; the scheme can naturally be accompanied by fragment
I agree that it may be desirable to extend Blobs to do a few other
things in general, maybe independent of better file reads. You've Cc'd
the right listserv :) I'd be interested in what Eric has to say, since
BlobBuilder evolves under his watch.
More information about the whatwg