Proposal: Span Context == Span about oteps

[yurishkuro]

This proposal stands as a counterpoint to #68.

Counterpoint or counterpart?

The main objective of #68 was to stop passing Span in the Context. One strong motivation for that is that SpanContext needs to be accessed in multiple places, whereas Span is quite often localized to a single scope where it is created, populated, and finished (there are, of course, exceptions with asymmetrical one-way interceptors).

I don't see Span as == SpanContext, because there is one important distinction: Span must keep an internal reference to the Tracer in order to be writeable, but SpanContext does not. If we always need a Tracer to get a Span, and Span is almost always local to a certain scope, then Span becomes just a convenience interface for write operations instead of having the same operations defined directly on the Tracer with SpanContext as an argument. However, if Span interface is the only way to capture data, then we're again forcing memory allocation regardless of the sampling state.

[jmacd]

@yurishkuro Thanks. I mistook your statement that removing Span "simplifies memory management" to be about managing Span state in the process, which is an SDK elective to do (or not do) in the current API.

Now I understand your concern is about memory allocations that could result from making Context Propagation independent of the Tracing SDK. Your point about the internal reference to a Tracer is well taken. I had written "span is essentially just a context with the addition of a process-wide sequence number", but that "essentially" masked an internal reference to the Tracer. I was thinking that two allocations (one for a Context, one for a Span=={Tracer,Context}) would be OK because it is O(1) memory per span either way, but you're right that we should be counting allocations particularly when, because of sampling, a span is not recorded. We wouldn't want to allocate unnecessary memory in that case. (As a tangent, in the OTel-Go repo we're slipping on this point.)

Now that I understand your concern better, I still think that Span == SpanContext if it weren't for this not-minor detail about having a Tracer reference. I think removing the Span from the API is an ergonomic loss, so I have few related suggestions:

1. Let the active Tracer be a part of the context. You wrote "whereas Span is quite often localized to a single scope where it is created, populated, and finished" and it's true. If the current Tracer was implied by the context, then Span == SpanContext holds. (h/t to @iredelmeier who made an equivalent proposal in her opentelemetry-playground repo.
2. If the aim is to avoid memory allocations when spans are un-sampled, then the Get Context API is problematic in its own right. I support removing this method from the Span interface to address this concern.
3. In OTEP #66 we are talking about "separating" the Context Propagation API from the Tracing API. I believe in this separation logically, but I don't believe we should actually decouple these members so completely that they are truly independent. We'll end up with more memory allocations. I would say they are "logically separate". An example technique might be to let the Context internally leave some storage for Tracer implementations to use. Let's suppose in the common case only one Tracer is active per Context, then a single field in the Context for the Tracer to use would be sufficient to avoid memory allocations and maintain Span == SpanContext.

[Oberon00]

While we would have had the chance to do this with OTEP66, I think it's too late now. Can we close this?