[Bug 15206] Add API for sending and receiving p2p application data

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