Metadata about instrumented component — library name, version

[ELLIOTTCABLE]

Need to add an API entrypoint for libraries to self-report what is producing traces — in OpenTelemetry, this is called 'instrumentation scope.'

Need to add a collector-agnostic method to report this — I do like OTel's format, which is a tuple of (name:string, version:string).

[c-cube]

So, to clarify, this would be potentially distinct for each span? Not just at initialization time?

[ELLIOTTCABLE]

I, huh. That's a good question.

On the one hand, path of least resistance — easy to 'open up' later, hard to 'close down'; that implies use the more restrictive "call a separate function" API?

… but on the other hand, currently, libraries don't need to do any initialization. They can just straight-up call Trace.with_span without any preamble, if they're not responsible for configuring the process-name or thread-name (which I imagine they won't usually be ...); but every library should, probably, include their name and version, to be a good citizen? In which case, a separate function substantially increases the overhead over "just throw a single Trace.with_span call in there to be nice. (It also opens the door to race-conditions wherein the application calles into library-code before it's had a chance to initialize itself …)

So, I guess, optional arguments to with_span is the best way to go; libraries can partially-apply it for their own usage if they want:

let with_span = Trace.with_span ~producer_name:"Mylib" ~producer_version:"1.0.3"

with_span ...

[c-cube]

It also depends on who uses that information. In theory, __FILE__ and __LINE__ already tell you a lot about where the span comes from! But I think additional information on with_span (or a standard k/v pair to use in the data dictionary) is a valid request because some tooling (OTEL…) will expect this information to be in a specific shape.

[ELLIOTTCABLE]

Okay, I've started to take the "standard k/v pair for the data dictionary" approach in my opentelemetry.trace patch (docs); so maybe that's a good thing to mirror here?

I'm using ("otrace.spankind", `String "CLIENT") there; so we can mirror that otrace prefix here — specify something like ("otrace.producer.name", `String "an-opam-name") and ("otrace.producer.version", `String "0.3.3")?

The patch here, if we want to go in that direction, would be:

1. docs, and
2. a similar Well_known module with fixed identifiers for those unchanging strings.