RE: Issue 440: Use interfaces not dictionaries

Martin Thomson said:

"This, I realize might seem a fine point, but I think that the idea that we use dictionaries for expressing all of the RTCRtpSender properties is a bad one. It creates a domain language that has similar properties to SDP.

If we have domain objects, we should describe them using interfaces. #350<https://github.com/w3c/webrtc-pc/pull/350> did that.

In an attempt to explain how dictionaries hurt, I'll use the request to express codec preferences as an example.

There are three options I can see are:
1. describe and identify codecs using an interface (as #350<https://github.com/w3c/webrtc-pc/pull/350> proposed)
2. describe and identify codecs using a dictionary (what I think Peter's design assumes)
3. describe codecs using a dictionary, but identify them using some new sort of identifier

I don't like option 3, so I'm going to talk about the drawbacks with option 2.

There, you get a dictionary that describes a codec. That has several parameters that are each effectively chosen by the application (they might get a copy of something to work from, but a dictionary is always entirely controlled by the application). That means that we have all the options we have for handling SDP: exact match, or allow them. And, if allowed, we have to define what is allowed, ignored or rejected.

All of that is unnecessary with an interface. And we can express, through the judicious use of readonly, what is permitted to be changed and what is not.



[BA] Except that the set of read-only attributes can and will change dramatically with WebRTC NV - and we will then need to make dramatic changes to the API which might not have otherwise been necessary.



It also leaves open the possibility that we are able to expose methods on those interfaces rather than have useless containers of data.

[BA] When a method returns a dictionary, that dictionary is automatically read-only, because changing attributes in it only affect the local copy.

When you change a method or create a new one that now requires some of the information returned in another method, the interface concept becomes an albatross, because at that point you need *both* the interface and a new dictionary including the same attributes!
"