> I think that, good or bad, the impression that users have that the DLQ > is not a "normal" topic
Thanks for your perspective, Matteo. I still prefer my alternative design that bypasses subscription creation, but it seems there is insufficient interest in it, so we should move forward discussing a DLQ specific feature and its implementation. > 1. Instead of modifying the current protocol, we can use producer > metadata to carry the init subscription What is the justification for avoiding the new protobuf field? If we add a structured field to a map of <String, String>, we are still modifying the protocol, even if we aren't modifying the protobuf. Thanks, Michael On Tue, Jan 18, 2022 at 8:38 AM PengHui Li <peng...@apache.org> wrote: > > +1 for adding the DLQ_init_sub to producer metadata so that we don't > need to introduce a new field in CommandProducer, and the new field > looks a little confusing > > Thanks, > Penghui > > On Mon, Jan 17, 2022 at 10:19 PM Hang Chen <chenh...@apache.org> wrote: > > > Thanks for creating this proposal Zike Yang. I have two ideas about it. > > 1. Instead of modifying the current protocol, we can use producer > > metadata to carry the init subscription > > 2. Please add auth for subscription creation when create topic by > > producer, otherwise, it will be easily attacked. > > > > Thanks, > > Hang > > > > Matteo Merli <matteo.me...@gmail.com> 于2022年1月12日周三 15:13写道： > > > > > > > If we want to hold that the DLQ is not a normal topic, then I can see > > > > why we would have a DLQ specific feature here. > > > > > > I think that, good or bad, the impression that users have that the DLQ > > > is not a "normal" topic comes from 2 factors: > > > 1. The experience with traditional messaging systems JMS and others > > > where the DLQ are handled in slightly different ways, compared to > > > other topics > > > 2. The name "DLQ" which in a way it's implying a "queue"... which can > > > be implemented on topic, using a subscription.. > >
