5985a0481e
First, the existing configuration parameter (use_datagram_transport) is now optional. The new field trial has two flag values: 1. Whether to enable the datagram transport (enabled) 2. Whether to use the datagram transport by default (default_value) The first is a kill-switch. It disables the datagram transport, even for applications which inject a datagram transport factory and specify use_datagram_transport = true. This allows applications which hard-code a datagram transport to switch it off via field trials. This flag defaults to true, to avoid breaking downstream projects which already inject and configure a datagram transport. It may be changed to false after updating downstream to set this field trial flag to true when required. The second provides a default value to be used in case the aforementioned use_datagram_transport parameter is unset. Applications which explicitly set use_datagram_transport will use that value. Applications which do not explicitly specify whether or not to use the datagram transport will use it (or not) according to the default_value flag. One goal of this flag is to simplify rollout in applications which already set field trials based on configuration, but require code changes for new RTCConfiguration parameters. A second goal is to provide platforms with a knob to control whether datagram transport is "opt-in" or "opt-out". This flag defaults to false, to prevent downstream projects from unintentionally enabling the datagram tranpsort. Bug: webrtc:9719 Change-Id: I521a5fa61c992e76e5081118678a1812a261d672 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144184 Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28435}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.