56d945233d
We now have two downstream users of stun.h, so it appears to be generally usable. I put this in a new dir networking/, but I'm open to suggestions here (maybe some things in api/ should move in there). I checked what our downstream users are actually using, and it's cricket::ComputeStunCredentialHash cricket::<constants> cricket::TurnMessage cricket::GetStunErrorResponseType cricket::StunAttribute::CreateAddress cricket::StunErrorCodeAttribute cricket::StunByteStringAttribute StunAttribute::CreateUnknownAttributes cricket::TurnErrorType cricket::StunMessage I reckoned that was pretty much everything in stun.h, so I didn't bother splitting it up. They don't use every function and constant in there, but all _types_ of functions and constants, so for the sake of coherence I don't think it makes sense to split it. There's some old stuff in there like GTURN which could arguably be split out, but it should likely go away soon anyway, so I don't think it's worth the effort. Steps: 1) land this 2) update downstream to point to the new header and target 3) remove p2p/base:stun_types. Bug: webrtc:11091 Change-Id: I1f05bf06055475d25601197ec6fefb8d3b55e8e3 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159923 Commit-Queue: Patrik Höglund <phoglund@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29822}
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.