Stabilize reflection APIs

[ejona86]

This is jumping the gun a little bit, because we don't yet have reflection APIs, but such APIs can use this issue as they are introduced.

[ejona86]

We'll probably want to rename ProtoReflectionService.getInstance() to newInstance() or similar. Otherwise it sounds like a singleton.

[ericgribkoff]

ProtoReflectionService.newInstance() was added and the package renamed to io.grpc.protobuf.services in #2767 and #2771

[dinowernli]

As part of adding reflection support to Polyglot [1], I would really love to run a reflection service from a FileDescriptorSet I provide (rather than having the implementation discover it from the currently running server).

It would probably not be too hard to add a newInstance(FileDescriptorSet) factory method which just serves a supplied (constant) descriptor set. What do you think?

[1] https://github.com/grpc-ecosystem/polyglot

[ejona86]

@dinowernli, why do you want a fixed descriptor set that's independent of the services supported? Are you wanting to add your own, remove some, or have complete control? I'd have expected the most advanced usage to be to implement HandlerRegistry.getServices().

[dinowernli]

@ejona86 I am not interested in changing the set being served, and I do not need the set being served to reflect the running services.

For instance, suppose I decide that my favorite grpc services (not necessarily running on the current server) are "FooService" and "BarService", then I would like to be able to run a grpc server which serves the file descriptors for "FooService" and "BarService" using the reflection API. Does that make sense?

[jnh5y]

@ericgribkoff others, should the ProtoReflectionService still be considered experimental?

That file has not been changed for 3 years.

[larry-safran]

Should consider changing it to not extend base class and provide a cleaner interface.