Re: Updated data stream API draft

On 02/02/2012 11:40 PM, Stefan Hakansson LK wrote:
> 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?
You call createDataStream() at only one end. The other end gets a 
ondatastreamadded event (or something).
An advantage of bidirectional streams is that it doesn't matter which 
end creates the data stream; with unidirectional, there either has to be 
a flag stating the direction or a convention that the data sender (or 
receiver) always creates them.
>
> 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").
Are we up to createDataSocket now?
I don't care much about the name.
>
> 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?)
I believe there's an underlying "ended" property, but am in the process 
of decoding the SCTP API, so can't tell for certain yet.
>
> //Stefan
>
>

Received on Friday, 3 February 2012 17:42:35 UTC