Conversation
| internal/advanced/specialized use as appropriate if typical | ||
| applications are not expected to use them. These are particularly | ||
| relevant for convenience libraries that wrap gRPC features but | ||
| provide their own tuning parameters. |
There was a problem hiding this comment.
I think there is no need to distinguish the last two categories for users as both are implementation details inside of C++ layer.
There was a problem hiding this comment.
@yang-g, if the last two categories go away, how does someone implementing code generation know what APIs are available at that layer? gRFC #28 and its implementation moved some things into an "internal" namespace, e.g., ::grpc::ClientReader<R>::internal::Create. This implies that some parts of grpc::internal are not implementation details, but part of a lower-level/more advanced API.
|
|
||
| [Previous work](https://github.com/grpc/proposal/pull/28) started to | ||
| separate internal-only from public sections of the gRPC C++ API by | ||
| moving selected compoennts to namespace `grpc::internal`. That effort |
There was a problem hiding this comment.
s/compoennts/components/
|
For consistency, please rename this file to |
|
Abandoned. |
6 participants
Continues the internalization effort started in #28 . Implemented in grpc/grpc#14648 .
Discussion thread at https://groups.google.com/forum/#!topic/grpc-io/LTFUwLhqEHE
Seeking feedback from @makdharma , @chwarr , and any others that care to discuss.
Earliest possible merger is March 30, 2018.