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

[whatwg] File API Streaming Blobs

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 24 Jan 2011 13:24:22 +0100
Message-ID: <op.vptbewzt64w2qv@anne-van-kesterens-macbook-pro.local>
(I removed the Chromium related list as I am not subscribed there.)

On Fri, 21 Jan 2011 21:35:53 +0100, Adam Malcontenti-Wilson  
<adman.com at gmail.com> wrote:
> XHR2 is one part of the APIs required for my use case as that is the
> easiest way to download for example a music file. However, while
> downloading, there's no way to pipe the download(ing) blob to the
> HTML5 Audio element as to play Audio it requires an object URL, and an
> object URL can (currently) only point to a static Blob, as well as the
> fact that a Blob cannot be appended. This would be important for
> listening streaming audio that needs to be processed in JavaScript or
> cached to persistant storage using the Filesystem APIs without having
> to wait for the entire file to be downloaded into an ArrayBuffer or
> Blob.

There is a plan of allowing direct assigning to IDL attributes besides  
creating URLs.

I.e. being able to do:

   audio.src = blob

(The src content attribute would then be something like "about:objecturl".)

I am not sure if that API should work differently from creating URLs and  
assigning those, but we could consider it.


> My suggestion was for another alternative version of Blob and/or
> createObjectUrl that mimicks how a HTTP request can be parsed and (in
> the case of audio or video) start playing before it has finished
> downloading (e.g. got to the content-length or had a connection close)
> by pushing content when it is appended to the blob and then the
> "virtual connection" can be closed when the Blob has finished being
> built by calling a close() function. I've also thought of other
> alternatives, but I'd make sure that there isn't already a way to do
> this with the current (specified) APIs, and I think this has the most
> other use cases as any data that takes a while to process can be
> streamed to the user or other parts of the browser.

Is there actually a good reason for the URL API to have behave in this way?


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Monday, 24 January 2011 04:24:22 UTC

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