Roch Devost

After thinking about this a bit more, right now the current proposal stores a span, but it doesn't use any method from the span, meaning it could be used to...

Not sure if it's the best way but the way we made it work was to extend all classes, so then our `Span` which inherits from `opentracing.Span` returns our `SpanContext`...

TypeScript has a distinction, but interfaces can actually extend classes, so we could say that a class is simply an interface with an implementation in a single construct. For the...

We replaced CLS with a scope manager that is as close to the specification as possible as we planned to bring that work to `opentracing-javascript` later on. Basically we had...

So far I have an implementation that we use in our tracer since we went GA. I'm currently reworking it to be simpler and more efficient. We've had many iterations...

> When finishSpanOnClose is used, the span will be finished only after all descendant asynchronous context have exited. The idea is to provide a way to handle asynchronous operations that...

@pauldraper After discussing this in Gitter, it seems the API doesn't have to be exactly the same as the spec, but the semantics should be the same. So in theory...

> Logically speaking, the callback is a child of the execution at the time the callback was created (not whatever execution completed the Promise). Just to be clear this is...

Simple implementation using CPS: https://github.com/DataDog/dd-trace-js/blob/cps-scope-manager/src/scope/new/scope_manager.js Sorry if the semantics are a bit weird in a few places as I didn't update the naming from the previous implementation.

@pauldraper One of the reasons the scope manager didn't happen in OpenTracing is that most of the effort has shifted to OpenTelemetry as it will replace OpenTracing soon. While the...