Bogdan Drutu

@mx-psi can you document why we stopped this effort until better understand the performance issue.

I don't think we should "delete" everything that is not used. Please at least consider to wait until @dmitryax reviews and approves this.

I would be concern to add traces for each individual component. Think about a simple processor that would not benefit.

And always N for the binary builds.

I am not sure if that covers all possible extensions (we may say that this may require a name change), but also supporting "...options" is free if no options are...

> Adding options would decrease the performance (by adding heap allocations) on a path where users expect high-performance. > Reference: https://github.com/open-telemetry/opentelemetry-go/blob/main/log/DESIGN.md#options-as-parameter-to-loggeremit Sure, but then we must have it extensible, so...

>EDIT: At minimum, we need to be able to set the log record severity level. Needed for: https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/processors/minsev/minsev.go I would prefer this in specs before adding support to be honest.

>The fact that something can be added in future does not mean that it can accept any parameters right now. Correct, that is why I did this PR.

@cijothomas thanks for the link. I think the word "superset" does not imply that the "standard attributes" must be allowed in the `LogRecord` attributes or body. At least some SIGs...

> Java is not aligned with the spec requirement that log attributes (i.e. not the body) are Map. We could add support for that, but nobody has asked. If this...