> 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.
Not all cases need a new field named init_subscription when creating producer, and users will not touch the metadata of the producer of a DLQ, so I think we can use the metadata to achieve the purpose more flexibly. Yes, it modifies the protocol, but in different ways. It like the message properties, we also introduce some system message properties such as __original_message_id in retry letter topic. Penghui On Thu, Jan 20, 2022 at 2:05 PM Michael Marshall <mmarsh...@apache.org> wrote: > > 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.. > > > >
