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. On Wed, Jun 15, 2011 at 9:59 AM, Ian Hickson <i...@hixie.ch> wrote: > On Mon, 21 Mar 2011, Simon Heckmann wrote: >> >> I found this thread >> (<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/02997 >> 3.html>) in the archive of this mailing list, but I could not determine >> if any decision was made whether this should be implemented or not. I am >> interested in this, because I came up with a scenario which would >> benefit from Streaming Blobs: >> >> I use the File API to locally store larger video files on the users hard >> drive. For security purposes I encrypted them with AES and use a >> javascript library for local just-in-time decryption. This is not yet a >> productive application bur more of a prototype. However, I experienced >> javascript manipulation of large data can be quite slow so we do not >> want the user to wait until the full video is decrypted/manipulated. >> Therefore I would vote for a way to append data to a Blob and the >> ObjectURL reflects these modifications. Maybe something like >> createStreamableObjectURL could be used for differentiation? >> >> Just wanted to express my thoughts because I think the whole File API is >> a great idea! > > I recommend forwarding your suggestion to the W3C public-weba...@w3.org > mailing list, which is where discussion of the File API specs more usually > takes place. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Adam Malcontenti-Wilson
