Lalit Kumar Bhasin

@DebajitDas @kpratyus Can someone help here?

@kpratyus @DebajitDas Can you please help here.

Moving to post GA, change will potentially improve performance, and a breaking change between exporter and reader. Planning for it post GA.

Agree, this is valid concern. Thanks for raising it. However, as said above, don't see how can we implement it without breaking existing API.

Thanks @sirzooro , @apelyk . I think we still have linking issues with the instrumentation libraries build against the otel-api using the older interface for TextMapCarrier, and the application compiled...

In theory, the example would be similar to any other TextMap Propagators - `HTTPTraceContext` propagator is used to transmit SpanContext information across network/process boundary, and similarly `BaggagePropagator` to transmit Baggage...

Have done quick update to http client-server example to demonstrate baggage propagation, if this is something you are looking for - https://github.com/open-telemetry/opentelemetry-cpp/compare/main...lalitb:opentelemetry-cpp:baggage-test?expand=1

> . New method RuntimeContext::Replace would help a lot here. What do you expect this method to do, replace the existing context with the Context passed as argument ?

Thanks for raising the issue. Just to add, the support for handling retryable/non-retryable response from OTLP collector is marked as optional feature in the specs - https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md#exporters. Which means, this...

Yes, actually I didn't find documentation for glog to write the data to appender/target. As an example for log4cxx - https://logging.apache.org/log4cxx/latest_stable/extending-log4cxx.html. But feel free to create a similar task for...