Lalit Kumar Bhasin
Lalit Kumar Bhasin
As I understand in the community meeting this week, it was agreed to go with the first option above i.e., delete all the HTTP clients not supporting HTTP 1.0, and...
> We are still pre 1.0, so its still okay? Or we can hold off from merging for few days as well and see if the spec actually gets stable....
@cijothomas Can we close this PR if you plan to open a new PR for bound instruments inline with the changes here?
The specs is marked as stable now - https://github.com/open-telemetry/opentelemetry-specification/pull/3887. Should be good to review it now.
We can also consider the use of parameterized tests for scenarios where only the inputs and expected outputs differ, to reduce redundant test code. Rust doesn't support it directly, but...
Agree. I feel there is value in exploring and implementing this feature at-least for the languages used in high-throughout, low-latency environments. I will open a similar support request for otel-cpp....
> I was under the impression that the user-facing API should adhere closely to the spec. The otel-cpp logging API has two parts 1. [user-facing API](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/api/include/opentelemetry/logs/logger.h#L252:L444) 2. bridge-api (rest of...
I believe `const char *` and `nostd::string_view` are sufficient for handling UTF-8 encoded strings, which can represent any Unicode character of sequences of 1 to 4 bytes. The use of...
supporting (or allowing to send/detect) different unicode formats eg - UTF-8, UTF-16 etc? I don't think this should be done. The string encoding should be supported as UTF-8 . Even...
> None has signed up for option1 and option4 yet - most likely I'll take a stab at them. I can take a stab at Option 4, if no one...