Should Tracers share all configuration objects with TracerFactory?

[z1c0]

The introduction of "named tracers" brought up an interesting question around shared configuration objects (e.g. SpanProcessors).

Currently, the specification states that SpanProcessors must be registered on Tracer instances (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-tracing.md#span-processor). With the introduction of named tracers, the logical counterpart for registering those would be the TracerFactory.
This however, brings up interesting questions:

• Should all Tracer instances created by the same TracerFactory share the same configuration objects? If e.g. these configuration objects change during the creation of 2 Tracers, should only the latter "see" this changes or should the former one receive those as well?
• Should a Tracer expose operations to manipulate those objects (e.g. add another SpanProcessor)?
• If yes, should these changes also affect the TracerFactory and all other Tracers created by it?

[z1c0]

This is the current suggestion that whould go into the SDK specification:

• All Tracer instances created by a TracerFactory share the same configuration. Changes to this configuration data (e.g. adding an Exporter) reflect in all Tracer instances. Technically this could mean that Tracers have a reference to their TracerFactory and access those configuration objects through it.
• Manipulation of those shared objects should only happen on TracerFactory instances. This means methods like addSpanProcessor should move from Tracer to TracerFactory.

[arminru]

This issue was resolved by PR #313, right?

[Oberon00]

No, I don't think so: #313 (comment)

I will look into Sampling and Propagators separately to have more focused PRs.

[bogdandrutu]

I think that by default all configs should be at Factory level and shared with all Tracers, and if needed we can allow special configs to be overwritten at Tracer level.

[carlosalberto]

Closing it, as it seems this was solved. Please re-open if this isn't the case.