- From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Apr 2016 19:27:39 +0000
- To: public-secondscreen@w3.org
> I briefly reviewed the state of the Streams specification [1] and wanted to share how it might fit in with the Presentation API. Thanks for your thoughts! I think we are in general aligned on direction :). More detail below. > It looks like from an API point of view, the suggested integration is to The names are traditionally `readable` and `writable`, and there is no need to hide them behind a promise (see below). > 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]. Conceptually, they should be instantiated along with the connection. The analogy with Fetch here is that a PresentationConnection is kind of like a Request; there is no fetch-like two-stage request -> response transition in the presentation API. > 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.) This is all taken care of by the streams infrastructure. E.g. reader.read() rejects when the stream's state is errored (which could be easily taken care of via an appropriate underlying source that ties together the stream's state and the PresentationConnection states). > What types are permitted to be written to writeStream? Must include at least DOMString, Blob, ArrayBuffer, and ArrayBufferView for backwards compatibility. Anything you wish; how to process the incoming data is up to your spec. > 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? I think either approach is OK. It sounds like it would be more convenient for your users to allow any type and do the conversion inside the stream implementation (i.e. inside the underlying sink) > 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. Yes; I definitely agree. As I said in the OP, the Presentation API should continue with its current API, and as streams become ready---with the writer side being the current blocker---consider adding new surface. > 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. Yeah, this should work really well. I expect such efforts to take place before any standardization work, and that such p(r)olyfills will be helpful when the time comes to work on something standard. -- GitHub Notification of comment by domenic Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/163#issuecomment-212078449 using your GitHub account
Received on Tuesday, 19 April 2016 19:27:40 UTC