- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 3 Feb 2012 08:40:10 +0100
- To: public-webrtc@w3.org
On 01/27/2012 12:20 AM, Justin Uberti wrote: > Attached as PDF. > > New in this draft: *Changes for Jan 2012 W3C meeting; tied DataStreams > to a PeerConnection; changed DataStream base class; added MTU for > unreliable streams; better WebSocket alignment (added other send() > variants, removed onreadytosend); added reliable and multiparty examples.* Some comments/suggestions - hopefully at least to some part useful: 1. I did not follow why it was an advantage that the dataStreams are unidirectional (this was discussed at the interim), but I note with this proposal bidirectional dataStreams are very natural (as a dataStream object is created at both ends, and the dataStream object can send and receive data). If we want to maintain the unidirectional property we would need to have different objects on the send and the receive side. Perhaps it is simpler to go to bidirectional? 2. I think the name dataStream is un-intuitive. I know that SCTP has a stream concept, but from the API perspective, you actually send discrete chunks of data. So I think something like dataSocket, peerSocket, dataPort, or something in that spirit would better reflect what the API does. (This is mostly cosmetics, and would mean that a common BaseStream class would not be used, and that local/remoteStreams could not be used for data - I don't have a strong opinion) 3. Perhaps rename pc.addDataStream to pc.createDataStream? (and in consequence of 2. above perhaps "addDataScoket"). 4. You need to define the event type for "onmessage", I think the MessageEvent can not carry "metadata". And define formats used for seqno and Timestamps. 5. It should be possible to send blobs (in addition to ArrayBuffers and DOMString's). 6. Seems strange to me to have states "LIVE/ENDED" on DataStream (dataSocket); it is as argued not really a stream, but rather a channel that can transport chunks of data. And presumably the dataStream (dataSocket) state would be tightly connected with the PeerConnection state - if the connection is fine data can be transported, and not otherwise. So to me it seems that for data the PeerConnection states are enough. (And if there are states LIVE/ENDED on both MediaStream and DataStream, should they not be in BaseStream? As should perhaps label?) //Stefan
Received on Friday, 3 February 2012 07:40:40 UTC