W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2015

[webrtc-pc] Use interfaces not dictionaries

From: Martin Thomson via GitHub <sysbot+gh@w3.org>
Date: Thu, 17 Dec 2015 04:03:54 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-122656973-1450325034-sysbot+gh@w3.org>
martinthomson has just created a new issue for 

== Use interfaces not dictionaries ==
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 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 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 

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.

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

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/440 using your GitHub account
Received on Thursday, 17 December 2015 04:03:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:47 UTC