gRFC L21: GPR API review

[Vijay Pai]

Hello grpc-io members,

If you don't use gpr_ functions, you can skip this message.

I have posted a new gRFC at https://github.com/grpc/proposal/pull/56/files . This is a proposal to curate the contents of the include/grpc/support directory, which is the public surface of the GPR API, as many of the entries in that API are not actually publicly needed or used. The result will be a smaller installation and fewer API surface points.

Thanks,

vjpai

[Christopher Warrington - MSFT]

>  This is a proposal to curate the contents of the include/grpc/support
>  directory, which is the public surface of the GPR API, as many of the
>  entries in that API are not actually publicly needed or used. The result
>  will be a smaller installation and fewer API surface points.

Seems reasonable for my use of gRPC, and the uses I've observed.

Here's a conservative list of the gpr functions that my codebase uses.

* gpr_set_allocation_functions & data structures
    * If this function stays, the getter should probably stay too.
* gpr_set_log_function & data structures
    * We're not using the gpr_log* functions directly.
* The gpr_time* functions, as these types are part of the C++ Alarm API
    * We're not using gpr_sleep_until

--
Christopher Warrington
Microsoft Corp.

[Vijay Pai]

Thanks for the feedback! Yes, everything in alloc.h definitely stays since those are used in multiple language implementations. Same with time and logging -- all the language bindings use them heavily. I think our sync and atm also stay since they are certainly used in some of our language bindings and presumably in community bindings as well.

[Vijay Pai]

I view the following as an interesting one. host_port.h provides two utility functions for name management: gpr_join_host_port and gpr_split_host_port . Both are used in several places inside core. They are also used in the core and C++ tests. So those are still fine with privatizing.

However, gpr_join_host_port is also used in the objective-C tests. Only in the tests, not at all in the implementation. And, as it turns out, those tests already dip into src/core in their includes. Thus, I'm going to say that host_port.h is privatizable even though objective-C nominally uses it. If objective-C later moves to its own repo, it will already have to deal with the privatized headers issue for testing anyway.

- Vijay