After spending some time working on implementing propagators, there's a pattern that feels a little weird to me: the fact that propagators can return back both SpanContext and DistributedContext. I think this is because having to have two context propagation objects is more difficult to understand: there may be a chance to simplify here.
Specifically, I don't think there's anything in SpanContext that precludes it from using the DistributedContext. This could look like:
- context_id: a unique identifier for this specific context (span_id could use this)
- entries: key/value pairs describing this context
- trace_id could fit into this
- feature / consuming service
- tracestate
There are a few major benefits here:
- language libraries would only have to worry about attaching a single object to a given request / context, rather than requiring some way to attach both to a thread / greenlet local.
- The propagators API can be simplified: no need to support multiple types.
If we go through with this, there may be value in passing in an existing DistributedContext object into extract. This enables multiple HTTPTextFormat or BinaryFormat propagators to add to the same object, enabling easy composition of multiple propagators.
After spending some time working on implementing propagators, there's a pattern that feels a little weird to me: the fact that propagators can return back both SpanContext and DistributedContext. I think this is because having to have two context propagation objects is more difficult to understand: there may be a chance to simplify here.
Specifically, I don't think there's anything in SpanContext that precludes it from using the DistributedContext. This could look like:
There are a few major benefits here:
If we go through with this, there may be value in passing in an existing DistributedContext object into extract. This enables multiple HTTPTextFormat or BinaryFormat propagators to add to the same object, enabling easy composition of multiple propagators.