Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interface vs dictionary #289

robin-raymond opened this issue Dec 1, 2015 · 0 comments

interface vs dictionary #289

robin-raymond opened this issue Dec 1, 2015 · 0 comments


Copy link

@robin-raymond robin-raymond commented Dec 1, 2015

For example, why is this an interface?

interface RTCRtpContributingSource {
    readonly        attribute DOMHighResTimeStamp timestamp;
    readonly        attribute unsigned long       source;
    readonly        attribute byte?               audioLevel;

I'm not sure how some structured data went from dictionaries and suddenly became interfaces. We must be very careful about interfaces vs dictionaries for simple structured data. There are many cases where a developer would need to construct these structured data from thin air (e.g. remote marshalled IceCandidates); We do not want the programmer being burdened with anything more than a simple json blob style creation, which is why this type of simple structured data must be dictionaries.

The only cases to make structured data as read-only interfaces instead of dictionaries would be when the information is returned by the API locally and used locally as an input parameter to another API where the data cannot be modified. For example, if we made the ICE usernameFrag/password being a constructible piece of data as an input parameter for the IceGatherer.

We must be careful in doing so though as it does add a burden onto the developer. Any API point where a real underlying object is used requires the programmer to hold onto the originally returned object instead of treating the information contained within the dictionary as just normal structured property data adds onto that burden. This makes the programmer unable to re-construct this structured data at will, or add hidden properties to the returned data, or insert the data into existing simple structured data (without creating hybrid simple/object mixed data).

PLUS even in the rare case this is still a bit of a headache for the ORTC engine. ORTC engines must be careful to trace the real object hierarchy back to a real internally constructed object to prevent developer from passing in object look-alike forgeries. Likewise, there are often easy alternatives than enforcing this object rule. In the case of ICE usernameFrag/password, the API could restrict receiving input usernameFrag/password combinations that could not have been possibly constructed by non ORTC engine entities by creating an internal "secret" when hashed with to the local ICE usernameFrag generates the associated local ICE password, thus removing the need to burden the application developer with anything more than simple dictionary. This technique is easily applied to many scenarios.

In other words, be careful with structured data becoming interfaces instead of dictionaries. This allows the programmer as much freedom as possible to consume structured data as dictionaries as they please (so the data becomes the programmer has their own private manipulatable and reconstructable copy of the data). If there is a true need for an interface for structured data, let's see if there is a simple alternative work around to prevent it.

Finally with RTCRtpContributingSource, I do not see the need to make it anything more than a simple dictionary.

That's my opinion.

aboba added a commit that referenced this issue Dec 1, 2015
aboba added a commit that referenced this issue Dec 1, 2015
Added change log for Issue 289: #289
@aboba aboba closed this Jan 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants