Bogdan Drutu

Unfortunately the proto style guide does not define this :( https://developers.google.com/protocol-buffers/docs/style

@mateuszrzeszutek micrometer is an API + Some implementation(s). I am not sure why that should translate into calls to our API instead of offering an implementation of micrometer that implements...

@mateuszrzeszutek > Micrometer instruments like Timer and DistributionSummary can be translated to native OTel histograms; micrometer does not have a "histogram" meter by itself, it basically exports each bucket as...

@jsuereth Nice to hear all these great things, but I want to also ensure that we are not adding unnecessary complexity to our APIs to support this, hence the "very...

@jsuereth also I do agree that they are good reasons to support unregister/close/etc for an instrument, but I don't think the reason should be that another API has it.

@jsuereth @mateuszrzeszutek is https://github.com/open-telemetry/opentelemetry-specification/pull/2317 resolving this? I don't have that feeling...

@jmacd I do agree with you about the locking problem, but I think the current SpanProcessor supports that implementation. Add the ReadableSpan to a list of active Spans onStart then...

@arminru I think you can use the presence of the end timestamp in the SpanData to determine if the Span is still in-process or finished. Does that solve your problem?

@arminru I see your point now, I think this is an edge case, and not sure if we need to design the API with this mistake in mind. I don't...

@vvydier the docker image that we use is generated from https://github.com/open-telemetry/build-tools/tree/main/protobuf, so go ahead and change the Dockerfile to include swift support.