Trace identifiers: strings vs. strongly typed

[SergeyKanzhelev]

SpanContext
OT: SpanContext exposes Trace Identifiers as strings, hiding the native representation.

OC: SpanContext exposes the underneath Trace Identifiers implementation, as well as TraceState and sampling information.

[bogdandrutu]

@carlosalberto has to talk to users if Tracestate + SpanBuilder (interface) is enough for them, if not please document why.

[tedsuo]

We want to recommend the new W3C standard, and have it be universally adopted. But we also want to support pre-existing context propagation schemes (such as B3).

Agreed: We would prefer exposing the strong (canonical) types for the new Trace-Context standard, and have that be the only supported form of in-process context propagation.

Question for Review during Release Candidate stage

If we use strong types, and only support Trace-Context for in-process context propagation. how do we support alternate network propagation schemes? Or can they all be handled solely through custom injection and extraction logic?

[yurishkuro]

Not sure what the conclusion is here, looks it it's still unresolved, but punted on later milestone.

There's also a consideration related to INVALID context (#75) - what does it return if it has no IDs?

[carlosalberto]

So I think SpanContext.INVALID is meant to be used like this:

if (context != SpanContext.INVALID) {
  // Use spanId/traceId
}

So, the user needs to check it like you do it for null. Is this correct @bogdandrutu ?

[yurishkuro]

Per #75 (comment), I am opposed to SpanContext.INVALID in the API. But even if we had it, it does not prevent the user from accessing the id getters on the context before checking for this constant.

Anyway, my point is that this issue shouldn't be closed and marked Agreed since the comments say that it was NOT decided and deferred instead.