To make it seamless and take advantage of protobuf tooling when making zipkin clients, I think it is a good idea to have .proto for all available API specs (including v1 and v2 http json). E.g. in Envoy we can purely use protobuf helps without a detour on using json lib like rapidjson.
Currently, zipkin APIs are represented as:
To make it seamless and take advantage of protobuf tooling when making zipkin clients, I think it is a good idea to have .proto for all available API specs (including v1 and v2 http json). E.g. in Envoy we can purely use protobuf helps without a detour on using json lib like rapidjson.
We can consider bringing: https://github.com/nytimes/openapi2proto to generate .proto from openapi spec.