Re: Proposal for API for Data

Cary agree with you on goal but I think they are still going to require use of the PeerConnection object to be able to set up all the ICE and everything else to get connected to the other side. 

I am imaging a simple example for use of the DataMediaStreamTrack and it won't require a call to getUserMedia but other than that, it seems like the simplest example is still going to look almost the same as a simple audio example.  I wish where was some way to make it much easier than that but I'm not seeing how no matter how we factor this API. 

On Mar 15, 2012, at 11:53 AM, Cary W FitzGerald wrote:

> ISTM that there are very important use cases for the data API that have nothing whatever to do with delivering media.  I don't necessarily have any objection to borrowing concepts from media delivery into the media API, but I see no advantage to it.  The data API should stand on its own and should make sense to a JS developer who is otherwise ignorant of RTC.
> 
> Cary.
> 
> On Mar 15, 2012, at 9:13 AM, Harald Alvestrand wrote:
> 
>> On 03/15/2012 02:34 PM, Cullen Jennings wrote:
>>> I had a proposal for the Data API for awhile and have circulated it privately to some folks but I had not sent it to the list because I wanted to keep the focus on the PeerConnection / JSEP stuff for awhile. However, I think I probably need to send this out. I think at the high level there is general agreement we need to be abel to send and receive data much like web sockets does, we need to be abel to create and destroy channels, and we need to be able to mark a channel as reliable or non reliable delivery. The API I'm proposing to do this is very simple.
>>> 
>>> Interface DataMediaStreamTrack : MediaStreamTrack
>>> {
>>>     attribute boolean reliable;
>>> }
>>> DataMediaStreamTrack implements WebSocket;
>>> 
>>> 
>>> This ends up getting the function to send and receive data as well as report errors fromWebSocket. Any library that takes a WebSocket can take a DataMediaStream. It unifies creation of a new stream to be the same as MediaStreams. So in the same way that a new Video track was created, you can add a data track or remove one. It is labeled in same way as the the other tracks and so on. It seems like i works well for data sources that are from the JS app and it also can be used with data sources, such as a sensor or game controller, that may be more controlled by the browser in the same way a microphone or camera is more controlled form the browser. That will allow for better real time performance of devices that produce a data stream instead of an media stream.
>>> 
>>> I'd like to discuss on one of the call the pros / cons of such an interface but right now I am heads down on the JSEP changes.
>> At one point I argued something similar....
>> 
>> the biggest worry I have with this approach is that it inherits a lot of stuff that doesn't seem to make sense, for instance:
>> 
>> - "mute" functions from the MediaStreamTrack: What does it mean to "mute" a data channel?
>> - track manipulations: what does it mean to add a DataMediaStreamTrack to two MediaStreams?
>> Perhaps nothing, since there still can be only one handler (or handler list) for the onmessage() function anyway?
>> - "url" and "extensions" attributes from the WebSocket API: Do they have meaning? Are "extensions" names from the same namespace as for WebSockets?
>> 
>> But I agree that getting the JSEP changes done is more important...
>> 
>>         Harald
>> 
>> 
>> 
>> 
> 
>

Received on Tuesday, 10 April 2012 14:11:34 UTC