[ADMIN] 2025 WISH LIST

[marcalff]

Happy 2025

This is a user survey, please indicate in comments what you think opentelemetry-cpp should focus on in priority this year.

Possible areas include:

• Better coverage of the opentelemetry specification
• Performance optimizations
• Internal documentation in the code, like doxygen
• External documentation, in opentelemetry.io
• Examples of usage
• Packaging
• Platform / Compiler coverage

Feel free to also suggest items not in this list.

[malkia]

So far deployed it internally to dozen of our game tools in order to track the status of an homebrew http caching server. Hasn't had any crashes directly related to it, and no one has experience any difference in performance, but possibly there might be a bit better ways to optimize these further:

- Performance optimizations - Less threads being used, less copying, allocations & deallocations

I've been using my own soft fork, which I merge often to the main one, and I've found that producing single .dll (for all three major platforms), and additional symbol files gives me easiest way to deploy it. I wonder where the header-only library approach is going, there are various singletons and these are tricky to have without actual binary body, it was not listed directly, but maybe as part of packaging. Packing api+sdk in single .dll fixes it (but could've worked in two, or more), but as I said, I didn't want to add extra "noise" to the rest of the team. Especially since we place all our binaries in single "bin" folder, and having (just making this up) - something like zlib.dll or curl.dll that may come from compiling from vcpkg may interfere with same named .dll in the folder. Static linking is also problematic as it creates opportunities for ODR violations, and I can't use delay loading with which I completely disable even loading the library. Hence:

- Packaging - precompiled dynamic libraries for Windows, Linux, OSX might be good to have exposing only `opentelemetry::` symbols.

[tristan-lanfrey]

memory allocation free API

auto span = tracer->StartSpan(...);

no reason that span should be std::shared_ptr, a good old stack allocated RAII class with clear move semantics is enough.

On the same topic, on the metrics side of things, I would like to be able to do something like:

auto view = std::make_unique<View>(name, description, unit, aggregationType, aggreagationConfig, std::make_unique<DefaultAttributesInjector>({{k1, v1}, {k2, v2},...}));

where DefaultAttributesInjector implements the AttributesProcessor interface.

This would allow me to not have to construct a map at time of measurement on my own thread for all those "static" attributes that decorate my metrics. This is almost possible already in terms of API, except it seems the library code that uses the AttributesProcessor is only written as a filter, so nothing can be injected.