Ben Plommer
Ben Plommer
> I know some users rely on parallelised decoding, which you should still be able to do. Yeah, you can always just deserialise your bytes and then decode them in...
Just to be clear - you're talking about allocating `KafkaConsumer`/`KafkaProducer` etc as `Resource[G, KafkaConsumer[F, K, V]]` etc, right?
Agreed. I think we should keep the current methods as they are and add variants with names suffixed with `In` with the extra type parameter.
I’ve put this in the v3.0.0 milestone, but hopefully we can do it in a non-breaking way as part of the 2.x series.
This is done for `KafkaAdminClient` and for `KafkaProducerConnection`, with the caveat that for `KafkaProducerConnection` it requires `Async` for the allocating effect purely so that `close` can be run on a...
We could consider adding the new methods to `KafkaConsumer` before 2.0 and deprecating the ones on `CommittableX`.
Another thing we could consider is for a `CommittableOffset` etc to expose a reference to the `KafkaConsumer` it belongs to - then the `commit` method can be derived from that...
@LMnet do you think this is something you'd like to pick up?
Could we improve the ergonomics by having a wrapper for the path dependent type? So we have something like ```scala sealed trait WrappedCommittableConsumerRecord[F[_], K, V] { val consumer: KafkaConsumer[F, K,...
> The more I think about this issue the more I leaning towards my last solution (when CommittableOffsetBatch can commit offsets from different consumers). That sounds reasonable to me.