Spike a bridge from new interfaces to current OpenTracing interfaces

[tedsuo]

• the goal is backwards compatibility: prove that a new tracer – built only to support the new tracer interfaces – can consume existing OT instrumentation.
• The goal for the spike is to identify and understand any places where the new interface design will make backwards compatibility difficult.

[bhs]

@tedsuo @bogdandrutu to be clear, the goal here is to write an implementation of an opentracing.Tracer that calls into the OpenFoo machinery.

If so, I'd propose we rename this issue Spike an OpenTracing Tracer that calls into the new merged project (or anything else that's unambiguous about the "direction" of the adapter).

[tedsuo]

Thanks @bhs. I clarified this somewhat.

I would prefer that the bridge code takes in the new interface, and returns the old interface. So it will work with any new tracer, not just the SDK. Given that the OpenTracing API is very abstract, and generally does not have accessors, this should be possible.

So, something like this pseudocode:

NewOpenTracingBridge(consensus.Tracer) opentracing.Tracer

[jkwatson]

The OpenTracingShim does this, correct? Can we close this issue?

[carlosalberto]

Sure, this is done. There are a few missing items/improvements but we already have issues for those cases. Closing.