Re: [whatwg] File API Streaming Blobs

Greetings Adam,

> 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@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
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029973.html>
>
> 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
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029998.html>
>
> 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.).
>
> Thanks,
> 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 
non-JavaScript APIs out there :) [1].  Blob objects as they are 
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 [2], 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 
identifiers.

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.

-- A*

[1] 
http://download.oracle.com/javase/1.4.2/docs/api/java/io/FileInputStream.html
[2] http://www.whatwg.org/specs/web-apps/current-work/#stream-api

Received on Wednesday, 22 June 2011 18:54:54 UTC