receiver/zipkin: discuss or outweigh benefits of supporting v1 Thrift API

[odeke-em]

I am coming here from #111 (comment)

For maximum compatibility it would be nice to ensure that even legacy services that use the v1 Thrift API for Zipkin can still send data to our interceptor. This issue is to request a survey of services that use the v1 Thrift API, discuss any implications etc.

[odeke-em]

@basvanbeek commented in #111 (comment)

If adding anything, I'd rather see us focus on adding Zipkin protobuf support.

https://github.com/openzipkin/zipkin-api/blob/master/zipkin.proto

[pjanotti]

As of today Envoy only supports Zipkin v1, unless we discover that the cost of this is really high we should do it.

[basvanbeek]

related: envoyproxy/envoy#4839

Maybe putting effort in having Envoy support V2 would be beneficial to both projects.

[flands]

Others may be using v1 as well so would be good to support this in OC

[odeke-em]

@flands just curious why did you close this issue for a fresh one? I ask because the discussion is going on here and the fresh one lacks context except by linking :)

[flands]

@odeke-em this is tagged as a discussion issue -- unless there is an objection, this is a feature definitely needed. The other issue captures the enhancement request. Other discussion/enhancement issues were handled this way -- is there a better approach?

[odeke-em]

@flands I see. I was just asking because we can transition issues from discussion by editing their titles and labels.

[codefromthecrypt]

fyi v1 json not v1 thrift. If you drop v1 thrift you won't hurt envoy.