Re: [presentation-api] PresentationSession should have stream interfaces!

Hi @domenic, this issue was tagged for consideration as the 
Presentation API moves towards Candidate Recommendation.   Thanks for 
your detailed answers earlier.

I briefly reviewed the state of the Streams specification [1] and 
wanted to share how it might fit in with the Presentation API.

It looks like from an API point of view,  the suggested integration is
 to expose a way to get the ReadableByteStream and WritableByteStream 
for a PresentationConnection, to allow two-way messaging with the 
browsing context that owns the other side of the 
PresentationConnection.  The WritableByteStream object could take 
"any" type, but it would need to be enforced that the object is 
serializable (through some mechanism) to allow messaging with remote 
user agents.

```
partial interface PresentationConnection : EventTarget {
  readonly attribute Promise<ReadableByteStream> readStream;
  readonly attribute Promise<WritableByteStream> writeStream;
}
```

Several details need to be worked out:

1. Are these streams instantiated with the PresentationConnection, or 
lazily only when the connection enters a "connected" state?  The 
approach above follows the latter, along the lines of the Fetch API in
 Chromium [2].

2. The canceled/errored states of the streams would need to be mapped 
to/and from the equivalent PresentationConnection states and event 
handlers.   I am not sure if the Reader events would need to propagate
 to/from the PresentationConnection states (i.e., when should the 
Promise from reader.read() reject.)

3. What types are permitted to be written to writeStream?  Must 
include at least DOMString, Blob, ArrayBuffer, and ArrayBufferView for
 backwards compatibility.

4. Do we leave serialization entirely in the hands of the page that 
obtains the WritableByteStream, specify a serialization format for any
 permitted type, or specify a TransformStream that the page should 
attach to the stream handle serialization?  

In terms of implementation, it looks like the major browsers are 
further along on the reader side, than the writer side.   Until a 
bidirectional API is in place, I think it will be hard to make 
concrete implementation progress.

One possible approach in the interim:  If there were an 
UnderlyingSource interface that could be implemented by a polyfill 
around the current API, then the page could construct its own 
ReadableStream/WritableStream objects.

[1] https://streams.spec.whatwg.org/
[2] 
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/fetch/Response.idl&l=30



-- 
GitHub Notification of comment by mfoltzgoogle
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/163#issuecomment-211527028
 using your GitHub account

Received on Monday, 18 April 2016 18:55:23 UTC