Allow SpanContext to be exposed directly on Span.

[anuraaga]

Fixes #999

This is a relaxing of the spec to give SDKs more options in presenting the API for SpanContext. See attached issue for why they may decide to do this. It's post-freeze, but the hope is that since this doesn't provide any additional requirement it could still be considered.

[anuraaga]

Prototype in Java open-telemetry/opentelemetry-java#1712 - we find the API to be far simpler

[Oberon00]

Have you checked the occurrences of SpanContext in the spec for what this means? E.g. what do we pass to the Sampler then? A full (Propated)Span? (Would be easier after #881).

[anuraaga]

Yup Sampler would get the Span too instead of getting the SpanContext out of the Span.

[mwear]

Right now, a span is meant to be write only at the API level. The only readable part is the span context. One drawback to inlining the span context into the span is that we'll lose that separation. I'm not saying we shouldn't do it, but this could introduce some confusion about which, and why some span properties are readable, and others are not.

[jmacd]

I endorse this proposal, having made similar statements in the past: open-telemetry/oteps#73. As for @mwear's statements about read vs. write conceptual APIs, this has also been discussed in open-telemetry/oteps#68.

If it were not for time and energy constraints, I'd suggest going further than this PR. The approach would be:

1. move the specification for all the Span write APIs to be static methods on the Tracer acting on Context (as 68 proposes)
2. the Span object stores a Context (becoming the SpanContext, as 73 proposes)
3. the Span write APIs are simply helpers that call the Tracer static methods using the stored Context.

It's too complex--this "going further" proposal can be one for the future.

[anuraaga]

Thanks @jmacd, I agree with that approach, and that it's probably going too far for now. At recommendation from the maintainers meeting, I have also filed #1033 which is an alternative to this PR that removes SpanContext completely. Conveniently you are the assignee on that one too :) I personally am not sure how important it is to have consistency among the languages on this topic by removing it completely as in that PR, or to give flexibility as in this one.

[Oberon00]

As commented on the issue, the case of the SpanContext as input for SDK sampler needs special care. Using the full span as input changes the meaning, making the two options not equivalent functionality-wise. There may be other functionality changes.

[anuraaga]

Does https://github.com/open-telemetry/opentelemetry-specification/pull/881/files alleviate the issue since it won't be SpanContext?

[Oberon00]

I think it does (#1022 (comment)) EDIT: Though it is not required, you can also just specify this more clearly here in this PR.

[Oberon00]

Although I requested changes, I'm in favor of this PR generally.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[anuraaga]

Going to go ahead and close this since don't think it will be merged.