Hi Magnus, Thanks for your interesting perspective. Your points are totally valid so I will revert this change to the previous version. I have also added the reasoning in the rejected alternative.
Best, David On Mon, Oct 24, 2022 at 4:49 PM Magnus Edenhill <mag...@edenhill.se> wrote: > > Hi, one minor comment on the latest update: > > > Den mån 24 okt. 2022 kl 16:26 skrev David Jacot <dja...@confluent.io.invalid > >: > > > * Jason pointed out that the member id handling is a tad weird. The > > group coordinator generates the member id and then trusts the member > > when it rejoins the group. This also implies that the client could > > directly generate its member id and the group coordinator will accept > > it. It seems better to directly let the client generate id instead of > > relying on the group coordinator. I have updated the KIP in this > > direction. Note that the new APIs still use a string for the member id > > in order to remain consistent with the existing APIs. > > > > We had a similar discussion for id generation in KIP-714 and I'd advise > against client-side id generation for a couple of reasons: > - it is much more likely for the client side prng to be poorly seeded, or > incorrectly implemented, than the server side. > This risks two different consumer instances generating the same id. > - it adds an extra dependency on the client, a uuid library/module, which > brings with it the usual plethora > of linking conflicts, package availability issues, etc. > - as for trusting the authenticity of the id; with server-side generation > we at least have a (future) possibility for verifying the id, would it ever > become an issue. > > > Regards, > Magnus
