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-weba...@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
