Re: [whatwg] File API Streaming Blobs

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.

On Wed, Jun 15, 2011 at 9:59 AM, Ian Hickson <ian@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-webapps@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

Received on Wednesday, 15 June 2011 14:04:50 UTC