Robert Pająk

@jack-berg, can you share any design flaw of the proposed design apart from not being complaint with the specification and the differences of what processors from other languages have to...

> The go PR#5470 proposal shouldn't be any less performant It is still (a little) less performant because there is more copying on the stack. In given benchmarks it shows...

> Alternatively, I am also fine to allow OTel Go to deviate from existing spec wording, and document it in OTel-Go repo. We strongly prefer to make it possible via...

> Maybe I could reword so that "shared" is recommended and "not-shared" allowed in specific languages as an exception e.g. for performance reasons. PR updated > The Go SIG is...

**SIG meeting notes:** needs more reviews.

> Filtering by not calling the next entry in the chain becomes a feature and users from languages which don't do chaining are left asking how they can achieve the...

> A chaining design would mean that there is no guarantee that all are called and the cross-language support of file configuration is diminished. Can you an example of a...

> Why? I thought the point of the definition of isolating processor is that the log records passed to `OnEmit` has an _isolated_ log record. It seems like an SDK...

> This is what I'm advocating for Why not specifying that users can chain processors and use the isolating processor (without introducing new types and methods)? Why would we want...

Changing this PR to draft. I am proposing https://github.com/open-telemetry/opentelemetry-go/pull/5636 in Go Logs SDK.