Magnus, thanks for taking a look at the proposal. Answers inline.
On Sat, Oct 10, 2015 at 2:03 AM, Magnus Edenhill <mag...@edenhill.se> wrote:
> Good write-up Ashish.
>
> Looking at one of the rejected alternatives got me thinking:
> "Modify request/ response formats to take namespace specifically.
>
> Solves the issue of delimiting string required in proposed approach and the
> issue with existing regex consumers.
> This definitely is the cleanest approach. However, will require lots of API
> and protocol changes. This is listed in rejected alternatives, but we
> should totally consider this as an option."
>
>
> I think we could actually achieve this without any protocol change at all
> by moving the namespace token to the common request header's ClientId
> field.
> E.g.: .. RequestHeader { ..., ClientId = "myclient@mynamespace", ... }
>
> That would provide the desired per-request namespacing and in theory the
> existing clients dont even need to be updated as long as the clientId is
> configurable (which it should be).
>
Interesting approach.
Pros:
1. As you mentioned, it does not require a delimiting string.
Cons:
1. A client can only interact with one namespace.
As Jay later suggested, and I agree, clients should be able to talk to any
namespace as long as they have the permission to access that namespace and
the namespace exists. Makes sense?
>
>
> My two cents,
> Magnus
>
>
> 2015-10-10 3:32 GMT+02:00 Ashish Singh <asi...@cloudera.com>:
>
> > Hey Guys,
> >
> > I just created KIP-37 for adding namespaces to Kafka.
> >
> > KIP-37
> > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-37+-+Add+Namespaces+to+Kafka
> > >
> > tracks the proposal.
> >
> > The idea is to make Kafka support multi-tenancy via namespaces.
> >
> > Feedback and comments are welcome.
> >
> > --
> >
> > Regards,
> > Ashish
> >
>
--
Regards,
Ashish
