- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 Jan 2012 04:52:58 +0000
- To: public-webrtc@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15206 --- Comment #7 from Justin Uberti <juberti@google.com> 2012-01-26 04:52:54 UTC --- Sorry for taking so long to reply. These are good questions, answers below. > Some more comments (refering to > https://www.w3.org/Bugs/Public/attachment.cgi?id=1061): > > * As a dataStream can be added to several PeerConnections, bufferedAmount > should be a PeerConnection property, since the throughput can vary. The same > applies to "onreadytosend". An alternative could be to allow a dataStream to be > connected to one PeerConnection only, but that defeats the purpose of the > dataStream - you could just as well have "send()" methods on the PeerConnection > object. This is a good point regarding attaching a DataStream to multiple PeerConnections. It may well be that this is more trouble than it is worth; I will re-evaluate whether it makes sense to allow DataStreams to be created independently from a PeerConnection. However, regarding the existence of DataStream vs send() on PeerConnection, I think DataStream provides a nice object-oriented API, especially when you have multiple simultaneous data streams. > > * For the "return -1 if unsuccessful, non-neg integer if successful" part: is > this supported by the protocol (i.e. is there a feedback mechanism in SCTP)? This is local feedback regarding whether there is enough buffer space to queue the outgoing packet; it should be independent of protocol. > * Does it really make sense that dataStream inherits from Stream? Agree. At this time, the Stream stuff seems too immature to tie ourselves to; while I liked having it as a parent class for MediaStream and DataStream, we could just use Object instead. The natural > thing would rather be that the "send" method of dataStream could take > DOMString, blob, ArrayBuffer and *Stream* as arguments; Stream to be introduced > once it has been added to the File API spec. This would align it closer to > WebSockets and XHR. For unreliable dataStream's, probably only DOMString's > would make sense (no point in sending a file unreliably). Agree, will address this. Note also that there > need to be some info on how to handle incoming binary data (as blob or as > ArrayBuffer; WebSocket has the "binaryType" attribute). Agree. > * The proposal is inconsistent with regards to how a DataStream is created. The > text says PeerConnection.createDataStream() while the examples and idls uses a > DataStream constructor. My oversight. Will rework based on what I decide regarding question #1. > * Why introduce new methods for adding/removing data streams (addDataStream() > and removeDataStream()) when the localStreams/remoteStreams attributes and > onaddstream/onremovestream event listeners are reused? Mainly, because the existing methods have media-specific syntax (MediaStreamHints in addStream, etc). > * Re-use of MessageEvent's as defined in http://dev.w3.org/html5/postmsg/ > should be considered for "onmessage" - it is already used for Server-Sent > Events and Web Sockets. Perhaps channel messaging could be used to align more > with the rest of the web platform? I don't think channel messaging is a perfect fit here, but using MessageEvent like WebSocket makes a lot of sense. Main question is how we can expose metadata like seqnum when using MessageEvent, will think this over. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.
Received on Thursday, 26 January 2012 04:53:02 UTC