Re: Updated data stream API draft

On 02/03/2012 06:41 PM, Harald Alvestrand wrote:
> 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.

Or different objects; the one creating the dataStream has a "sink" and 
the the receiver a "source". But I think it is simpler if they are 
bi-directional.

>>
>> 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?

Yes, that is what I meant.

> I don't care much about the name.

Agree, it's not that important.

>>
>> 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.

OK. If so it might make sense to expose it to the app.

>>
>> //Stefan
>>
>>
>
>

Received on Friday, 3 February 2012 17:50:15 UTC