- From: Domenic Denicola <notifications@github.com>
- Date: Mon, 17 Sep 2018 19:44:06 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 18 September 2018 02:44:27 UTC
Yeah, I second @lgrahl's points, and remain optimistic that as this API graduates out of the incubation and prototyping phase into something that browsers would be willing to implement and ship, it aligns with other web platform streaming primitives and reuses that infrastructure. Much like the previous transition across the platform from ad-hoc callback interfaces to a standardized promise interface, an interoperable base primitive that solves many of the hard problems makes things easier for developers and spec-writers alike. I imagine that new RTC APIs will want to join that work, and look forward to working with them to make it happen. With any luck it should reduce the effort for the spec authors and implementers both. E.g. the reinvention of the high-water mark concept and the tracking that goes along with it in https://github.com/w3c/webrtc-quic/pull/53 and elsewhere would be unnecessary if the streams infrastructure was used. /cc some of the active folks in the recent pseudo-streams work, @pthatcherg and @aboba. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/303#issuecomment-422235381
Received on Tuesday, 18 September 2018 02:44:27 UTC