Closed mlavrent closed 2 months ago
@mlavrent - Thank you for your PR - I just responded on https://github.com/open-telemetry/opentelemetry-dotnet/discussions/5794. We are not planning to add/support it at the moment. For .NET, the goal is to remove the dependencies from these classes and implement a custom serializer(https://github.com/open-telemetry/opentelemetry-dotnet/issues/5730).
Closing, base on @vishweshbankwar comment.
@mlavrent If you still want to have this standalone package I think it would be fine to have over on https://github.com/open-telemetry/opentelemetry-dotnet-contrib. We probably won't take it as a dependency for anything in this repo but that doesn't mean it couldn't be out there for users to consume for their own purposes.
Sweet @CodeBlanch - I'll see if I can add this there in the meantime as a stop-gap before the custom protobuf serializer is developed over here :).
Design discussion issue #5794
Changes
Currently, the OpenTelemetry protobuf definitions are provided here.
Other languages provide bindings for these protobuf models as a package in their respective packaging systems:
This may be useful for folks wishing to write their own custom OTLP receiver or otherwise serialize/deserialize using the protobuf definitions. We could also factor the serialization/deserialization logic and protobuf files out from the OTLP exporter in a future PR (potentially moving the encoding/decoding logic to this package too).
Propose to call this package OpenTelemetry.Proto, and essentially add opentelemetry-proto as a submodule.
Want to hear your thoughts on if this is worth doing - if so, I'm happy to take this on to support some things I'm looking to do with this package as a standalone (as opposed to using it as part of the OTLP exporter).
Merge requirement checklist
CHANGELOG.md
files updated for non-trivial changes