Of possible interest in this discussion: Rachel Blum and I recently suggested using Stream to represent the output of the MediaStream Recorder (on public-media-capture). These streams would obviously have internal structure like a UTF-8 stream would. Virtually all use of Stream will be transporting data like text, HTML, or media, with internal structure. That makes me think that such matters are better just left to the consumer, and that Stream should be only a byte transport. One of the most useful things we'd like to see in Stream for the media recording case is discard-on-read semantics. Reading the thread, it seems this is something everyone thinks is a good idea. I think Takeshi's suggestion of a Promises-based API that would be used on Stream itself matches well with that. The other stream-based feature we'd like for media recording, and which it sounds like would be nice for XHR as well, is flow control for coordinating the stream builder and consumer. These threshold values are in the existing spec for the builder side -- the builder can get events when the stream buffer depletes beneath a threshold. It'd be nice to have this for the output side, so that the consumer doesn't loop tightly with tiny reads. One thing that would help with this is having a Stream.available property to detect how much content is available for a low-latency read. In terms of relating to the File API, perhaps the best strategy would be enabling an easy way to connect a stream builder to a File, and a stream reader to a Blob. I don't know that making Stream and Blob/File objects have an inheritance relationship is a good goal. I think that's what Anne and Takeshi are saying too. On Wed, Jul 17, 2013 at 11:46 AM, Anne van Kesteren <annevk@annevk.nl>wrote: > On Wed, Jul 17, 2013 at 11:05 AM, Jonas Sicking <jonas@sicking.cc> wrote: > > What do you mean by "such features"? Are you saying that a Stream zip > > decompressor should be responsible for both decompressing as well as > > binary->text conversion? And thus output something other than a > > Stream? > > I meant that for specialized processing you'd likely want more than > just decoding. You mentioned HTML parsing which requires a fair amount > more. And if it's just decoding, we could extend > TextEncoder/TextDecoder to work with Stream objects. > > > -- > http://annevankesteren.nl/ > >
Received on Friday, 2 August 2013 16:52:52 UTC