Franz Busch

@Lukasa @dnadoba any idea why the benchmarks regressed on the nightlies here?

Overall, I am open to changing both `LogHandler` and `Logger` to accept `error`s since this often carry a lot of additional information as pointed out here. However, I would like...

I personally think it makes sense to add an `error` parameter to the `log` method of both `Logger` and `LogHandler` with a default implementation for the `LogHandler` that just extracts...

> I'll point out that there can be valid LogHandler implementations today that will not be able to implement this new requirement. For example, a LogHandler that transparently forwards all...

> This part is interesting. So let's assume we keep user types from leaking down to the `LogHandler`s by catching and flattening errors on the `Logger` level. We need to...

> How about we use the word `count` instead? For instance, we could rename the protocol to `NIOOutboundBufferedBytesCountableChannelHandler` and the public method to `countOutboundBufferedBytes`. This change would preserve the idea...

> I'm generally ok with `NIOOutboundByteBufferingChannelHandler`. However, my main concern is that this name might be a bit misleading. Two new protocols are not intended to help provide buffering mechanism...

Overall I'm sympathetic to the problem. Not only from an attack angle but also from a correctness angle. I have implemented and reviewed many channel handlers over the past years...

I think this is a good idea but we should have this for every single log level.

> 1. How do we want to deal with 6.0 not supporting `sending` correctly? Gate this feature behind `6.1+`? Given that we intro it as SPI, we might be able...