- From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
- Date: Wed, 28 May 2014 17:24:19 +0200
- To: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
On 05/28/14 11:18, Harald Alvestrand wrote: > On 05/28/2014 10:52 AM, Wolfgang Beck wrote: >> Adding another data transfer protocol on top of SCTP wll not solve >> your problem. >> >> The Websocket-style API is the problem. >> It does not allow the JS to delay reception and does not tell you >> when it is apporpriate to send more data. >> >> Sending a chunk and wait for an ACK? That means you will spend most >> of the time waiting for Acks instead of >> transmitting data. Of course you can somehow negotiate how many >> chunks you can send without having to >> wait for an ACK. Now you have re-implemented a substantial part of >> SCTP, probably with more errors and less sophistication. >> >> What's wrong with the Streams API? > > The first thing wrong about the Streams API as described in the link > below is that it does not preserve message boundaries; a Stream is a > sequence of bytes. > > Our chosen abstraction is a sequence of messages. > > Something like the Streams API may be a Good Thing (and applicable to > websockets too), but the current proposal just has the wrong model for > our purposes. > > If you have a suggestion to bridge the gap, please bring it forward. Not preserving message boundaries is valid objection. Maybe we can still borrow the Stream API's concepts. Either way, it is an API problem, not a protocol problem. File transfer requires interaction with the File API. which has its own set of callbacks. Ideally we'd have a common pattern for operations where we need to wait for completion (sending a chunk, writing a chunk to file) and get informed about available data (a chunk was received from a data channel, a chunk was read from a file). Ideally, those operations are composable (check if the File API is ready to write another chunk, check if there is data on the data channel; check if the File API has read a chunk, check if a chunk can be send via the data channel). Wolfgang
Received on Wednesday, 28 May 2014 15:24:49 UTC