Closed thepwagner closed 5 years ago
I thought we had actually removed everything but protobuf in the most recent release, but yeah, we're generally in favor of moving all of the tracers towards only using proto.
The changes look fine overall and I'm fine with the refactor if you want to take a stab at it, or we can merge as-is.
@austinlparker thanks for the feedback!
I've migrated protoConverter
, reporterID
and attributes
from each collectorClient
implementation to the tracerImpl
.
That leaves collectorClient.Translate()
operating on an already converted protobuf request, but otherwise unchanged. (I toyed with removing reportRequest
intermediary, but didn't want to mess with the semantics/error behaviour of Translate
)
Some tangential changes snuck into the HTTP collector too:
context.Context
in Translate()
is just overridden by Report()
, so drop it.accessToken
header can probably be set with the other headers(?)Is there any timeline for merging/releasing this?
Whoops, slipped off my plate. I'll get to merging this today!
This is released in v0.17.0
This adds the ability to inject a custom protobuf transport. This requires migrating protobuf conversion from
collectorClient
s to thetracerImpl
, which is a hard step away from non-Protobuf transports.I'm running tracers in a network without access to the collector, so I'd like to bring my own transport API. The
grpcCollectorClient
is close, but crufty.