If it is all possible I think we can introduce request pipeline architecture for producer, broker and consumer (does not have to be done all at once), that way, security, quota, encryption, serialization, compression all can be done as plugable components. One can freely stack them up or tear them apart at the configuration level. Each component can have its own design and implementation. Any deployed can choose what interest him or her. Components have no dependency among each other. New features can be easily added/tried/removed/abandoned. When I looked at our code, instrument this so called pipeline can be very easy. Wonder if any of you guys interested.
Thanks. Sent from my iPhone > On Apr 15, 2015, at 4:14 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > I think this should be a fairly minor follow-up item to have the quotas key > off of user rather than client id. The advantage of starting with client.id > is that it decouples the security work from the quota work in the short > term and provides a mechanism for those using Kafka without authentication > to still enforce quotas. > > On Wed, Apr 15, 2015 at 6:15 AM, Adrian Preston <prest...@uk.ibm.com> wrote: > > > Hi, > > > > I've been investigating using Kafka for a multi-user system that applies > > quotas at a per-user level. Reading through KIP-13 and KAFKA-1682, I > > wondered: are there any plans to link together the security principal and > > client identifier in some way? Currently it appears these are separate > > concepts - so I can't see any way to apply a quota based on the > > authenticated identity of a user. > > > > > > Regards > > - Adrian > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > >
