Why do ISpan/ISpanContext not have parity in BaggageItems?

Might be a question for the specification, but from my reading, the specification is explicit down to this level.

ISpan exposes SetBaggageItem and GetBaggageItem(string), but ISpanContext only allows user to retrieve ALL of the baggage items via GetBaggageItems(). Since ISpan is supposed to be storing it’s baggage in the ISpanContext, this seems like an artificial limitation of the API.

[yurishkuro]

“why then does SpanContext expose BaggageItems at all when it could just be a field-less interface?”

as I said, it didn’t really need that for most cases, aside from one obscure use case that wasn’t possible otherwise. That use case needed all baggage items (it didn’t know which items are there), and “all” is a smaller API surface than “get by key”.

“why did we bother with the interface?”

That confusion puzzles me - you need an interface to define an API, even if it’s an empty interface. And as @cwe1ss mentioned, there is a proposal to extend that API to return implementation-agnostic representation of trace/span IDs.

kind of an implementation -> API rather than an API -> implementation lifecycle

I wouldn’t say that. It is of course true that there were existing implementations at the time of API design, but the goal was to enable vendor-neutral instrumentation, i.e. end-user use cases, not to provide an SPI for tracer implementors. Where existing implementations played a role was in them saying “you can’t add method X to the API because my tracing system does not have even a concept of X”. The API is first and foremost end-user facing, if there is no concrete end-user use case, we try hard not to extend the API for it (tracer implementations can cast and do whatever).

[ndrwrbgs]

Thanks for taking the time to reply Yuri! I’ll close this issue.