Remove Context interaction from Tracer/CorrelationContextManager

[carlosalberto]

From #424:

Should the Context interactions be part of the Tracer/CorrelationContextManager, or can we have a ContextUtil class in the each package that handles this interaction? This would mean removing members such as:

• Tracer.getCurrentSpan()
• CorrelationContextManager.getCurrentContext()

Now that Context is a well defined notion, probably we don't need an abstraction on top of it.

[dyladan]

I'm confused. Is this issue in favor of removing Tracer? What would be left on the tracer if span operations are removed?

[bogdandrutu]

On the Tracer we will still have the "Span" creation API which is important in order to be able to provide different implementations for the "Span".

[carlosalberto]

@dyladan Updated the description to make this clear, hope that helps ;)

[dyladan]

So the Tracer will no longer modify context, but may still read from the current context (in order to find parent for a span, etc). Does that mean startSpan is the only method left on the Tracer now that Propagation is removed?

[bogdandrutu]

@dyladan I would say most likely yes at this point. Similar with Meter where we have methods just to create the instruments.

[dyladan]

Be aware that this language will probably need to change if this proposal is accepted https://github.com/open-telemetry/opentelemetry-specification/pull/424/files#diff-ea4f4a46fe8755cf03f9fb3a6434cb0cR132 as it implies that the Tracer is accessing/setting context values

[carlosalberto]

@dyladan Oh definitely. This part will be updated if we proceed with this.

[toumorokoshi]

+1 on this idea, but are there thoughts on being stricter on things like tracer having span setting methods?

I like as much consistency as possible between APIs, today I'm able to run through an API I'm familiar with (Python), and quickly relate the concepts to other languages. If, for example, setting current span in the tracer becomes popular in one language, and is non-existent in the other language, people will have to remember that detail as a caveat.

I personally advocate for exclusively having context set methods in a context util object, and disencouraging setter methods elsewhere.