Draft Proposal for Streams API

There has been discussion in this group now and again about the need for stream
support as part of the File APIs including recently in the threads about Streaming
Blobs [1] and XHR streaming [2]. I've also had several private conversations with
members of the WG about the need we see for this kind of stream support.

Initially, we thought that supporting a streaming Blob was the correct solution
but we ran into a number of issues with this as we investigated further. First of
all, people were confused about using the term "Blob" to represent something of
unknown size. Secondly, we received guidance from a number of people to keep the
two concepts of Blob and Stream separate.

Back in March, we provided some suggestions about using streams in the context of
Media Capture and Speech with our submission to the HTML Speech XG [3].
Specifically at that time we said:

  We propose the addition of a stream type. While this document does
  not present a detailed design for this type, we assume a Stream is
  an object that:

    1. Has a content type;
    2. Has unspecified length;
    3. Can generally be used in the same places Blob can be used, for
       example URL.createObjectURL().

Over the last six months, we have refined our thinking further and would like to
submit a proposal for review by the working group that provides that detailed
design. We believe that this work is part of the chartered deliverables for File
API (and includes XHR support):

    Streams API - http://html5labs.com/streamsapi/

We recognise that there are a number of different proposals for using stream-like
objects elsewhere in the web platform, usually for very specific use cases. What
we have tried to define here is a Stream object that is as generic as the Blob
object defined in the File API spec. 

As we started building applications with richer access to devices on the system
including files we found the lack of support for an object representing
asynchronous data of (initially) unknown size was important. Section 11 of the
proposal provides examples of the scenarios we have in mind. To start to address
this gap, we have implemented a preview of this mechanism in IE10 Platform
Preview 3 behind a vendor prefix (e.g. MSStream) to gain more implementation
experience.

We look forward to hearing feedback on this proposal, which we've framed mostly
as a delta against existing drafts in this working group.

Thanks,

Adrian.

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0725.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
[3] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#streams

Received on Thursday, 22 September 2011 18:35:58 UTC