- From: Domenic Denicola <d@domenic.me>
- Date: Tue, 14 Apr 2015 19:38:55 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, Matthew Wolenetz <wolenetz@google.com>
- Cc: Aaron Colwell <acolwell@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, WHATWG <whatwg@whatwg.org>, Brad Hill <hillbrad@gmail.com>, Ryan Sleevi <sleevi@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>
From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Anne van Kesteren > Well, except now you make yourself depend on some definition of an > opaque stream object which nobody has defined yet. Perhaps we should, > but that will take longer and won't be less work (though maybe less work > long term). I think opaque stream is a good primitive to have. Given that we'd like the Streams API to be a general mechanism for composition of data streams, and given that our platform necessarily makes some data streams opaque, it'd be good to introduce a type for this. It would act like a readable stream without any ability to get a reader (so, you can pipe it to trusted places, and cancel it, but not read individual chunks). This would allow some subset of the general stream-consuming code that developers write to "just work" with cross-origin/mixed resources and any other opaque cases. I also imagine it won't be too hard to spec, as the point of an opaque stream type is that most of its methods consist of "magic happens here" (roughly speaking). If there is consensus on this direction I am happy to get working on a PR for the Streams Standard that people can review. Given that they only have a few methods, nailing down the exact semantics should be pretty quick.
Received on Tuesday, 14 April 2015 19:39:23 UTC