Tracer resolution default

[carlosalberto]

Currently the spec defines this as:

Tracer provider is an internal class used by the global registry (OpenTelemetry) to get a tracer instance. The global registry delegates calls to the provider every time a tracer instance is requested. This is necessary for use-cases when a single instrumentation code runs for multiple deployments.

But there's no actual mention on what should be loaded if there's no explicitly defined Tracing component - should it try to no-op one (API only), or should it try the actual SDK? (My feeling is that the former should be the one)

This came up in OpenTelemetry in Python (open-telemetry/opentelemetry-python#29).

[z1c0]

Having the no-op tracer as default seems like the most reasonable approach.
Trying to load the actual SDK would either mean tight coupling of API and SDK or having to rely on reflection, dynamic loading, ...

[jmacd]

See also open-telemetry/oteps#45

[tedsuo]

Decision: observability APIs are write only, so a default implementation will be a No-op.

When context propagation becomes a separate layer, it may have a default implementation. open-telemetry/oteps#66