openproto/protoconfig

ProtoConfig 1.0: Open Standard for using, defining, and consuming software configuration input in a unified way.

protoconfig's Issues

Standard should specify discoverability?

Discoverability of the protobuf is a big problem in the ecosystem (e.g gRPC). Ideally, binaries are self-descriptive. There might be huge value in bringing
this topic here, but it could be also subject to another specification (as per Focus on one thing well).

For example:

CPD Shall be embedded in the software executable/binary and available on demand. Note that this specification does not force any delivery mechanism as long as there is one.

• It's recommended to expose protoconfig.v1 argument or flag that will output embedded CPD in .proto format.
• For web applications it's recommended to also expose /protoconfig/v1 endpoint that returns CPD .proto format.

The above assumes CPD is self-contained which conflicts with the above about extensibility.

Generate new config boilerplate + makefile

Common stuff that needs bit thinking

Improve Protobuf tooling.

To make this really good standard, we need to improve the ecosystem. It's not bad (e.g IDE proto files support exists, tools are reliable, version etc), but there are rough edges:

• protoc does not automate path lookups, it's hard to find correct paths (e.g all has to be absolute, for some reason)
• have a bit confusing errors
• requires multiple multi-lang binaries (protoc, protoc-gen-go protoc-gen-go-openconfig), with strict naming (plugin system)
• It's hard to discover out the definition proto used from API/Server/Executable

All is solvable though. Help & ideas welcome 🤗