[presentation-api] PresentationSession should have stream interfaces!

domenic has just created a new issue for 
https://github.com/w3c/presentation-api:

== PresentationSession should have stream interfaces! ==
Hi all,

My apologies for not looking bringing this up this sooner. But I just 
looked at the spec for the first time, and realized that 
PresentationSession is basically duplicating a lot of the work and 
interface that is going in to 
[streams](https://streams.spec.whatwg.org/)! I'd like to see if you 
are interested in, in a future revision, adding direct support for the
 stream data types.

Similar to promises for async operations, readable streams are meant 
to be a universal primitive for things that need to be read from, and 
writable streams for things that need to be written to. So, adding 
readable and writable stream interfaces to PresentationSession would 
let them interoperate with the rest of the streaming ecosystem, and be
 consumed by libraries that are meant to operate on generic streams. 
For example, you could do things like

```js
fetch("http://example.com/somebytes").then(res => {
  res.body.pipeTo(myPresentationSession.writable);
});
```

to set up a [pipe chain](https://streams.spec.whatwg.org/#pipe-chains)
 between the data retrieved from fetch and that sent to the 
presentation session. It would properly apply backpressure and so on. 
Or you could do streaming uploads of received data, with

```js
fetch("http://example.com/dest", { body: 
myPresentationSession.readable });
```

---

The concrete proposal would roughly be that we add a `.readable` 
property that is a ReadableStream, and a `.writable` property that is 
a WritableStream. The chunk type would be Uint8Array, most likely, to 
match fetch. You could use these directly (e.g. `const reader = 
session.readable.getReader(); reader.read().then(processNextMessage)`)
 to get the same functionality as your current `"message"` event and 
`send()` APIs---although the pull-based `read()` API has [some big 
advantages](https://github.com/whatwg/streams/blob/master/Requirements.md#creating-readable-streams)
 over the push-based `"message"` one. But the real benefits would 
come, as shown in the examples above, when used by any generic 
stream-consuming or producing APIs. Again, the situation is analogous 
to promises---slightly nicer, but the real benefit comes from building
 an ecosystem that uses them.

We wouldn't modify any of the existing stuff on 
PresentationSession---just like we have legacy APIs in the platform 
that have both promise and callback interfaces, this would be an API 
that has both ad-hoc reading/writing interfaces and standard 
streams-based ones. If I'd caught this sooner, maybe we'd have a 
chance, but as-is it seems too late, especially given that I still 
have some work to do before I'd say writable stream is stable enough 
for other specs to consume :-/.

---

WDYT?! If this sounds agreeable, I could try to put together a PR. 
You've already done much of the hard work by specifying "send a 
message through a PresentationSession S" and friends. It would largely
 be setting up some glue for creating the streams appropriately, as in
 https://domenic.github.io/streaming-mediastreams/#msr-constructor

See https://github.com/w3c/presentation-api/issues/163

Received on Thursday, 20 August 2015 17:20:46 UTC