Current API defines some methods that expect an Object as argument, or that return an Object. For example, when Alice needs to signal Bob that she will send an Opus audio track with payload-id=98 and SSRC=1234, something like this should be coded:

// Alice gets her sending track description/details and signals them to Bob: var rtcTrack = rtcConnection.track(audioMediaStreamTrack); signalingChannel.send(JSON.stringify({ "track": rtcTrack.getDescription() }));  # Bob receives it and instructs his browser to receive such a track: signalingChannel.onmessage = function(evt) { var message = JSON.parse(evt.data); if (message.track) { conn.receiveTrack(message.track); } }
The RTCTrack.getDescription() method returns a full RTCTrackDescription Object with all the required fields for defining the track. So, would it make sense that the receiver should apply each of those fields one by one in a setter/properties fashion? Honestly I see no benefit.

Another similar question is regardless the RTCConnection.connect() method which requires as argument a RTCIceDescriptionObject, which basically contains two fields: ICE userFrag and ICE passwd. Should it be better to make them properties? But, why? Two ways:

Current one:

myConnection.connect(remoteIceDescription);
With properties:

myConnection.remote.ice.userFrag = XXXXX; myConnection.remote.ice.passwd = XXXXX; myConnection.connect();
Honestly I think that, sometimes, passing a full Object is better. Instead, setting track fields one by one means that it could get incomplete (what if you set the RTP SSRC value but not the track kind “audio” or “video” nor the payload-id or receiving codec or codecs?).

Comments:

Gustavo Garcia says:
August 28, 2013 at 10:10 pm

I prefer the usage of objects, the API is cleaner and more convenient for developers in my opinion.