Hi Bo, Because the topic name is not a part of MessageIdData. It's only used to find the correct internal consumer of a multi-topics consumer.
> All I can think of is PulsarApiMessageId extend TopicMessageId(PIP-224[1]) > right? No. The `TopicMessageId` could only be used in a multi-topics consumer. For a single-topic consumer, wrapping the topic name is redundant and might break the existing behavior. In this case, if `PulsarApiMessageId` extends `TopicMessageId`, the `getTopicName()` method should return null, which is not a good design [1][2]. After both PIP-224 and PIP-229 are approved, the `TopicMessageIdImpl` will implement both `PulsarApiMessageId` and `TopicMessageId` interfaces. Other `MessageId` implementations only need to implement `PulsarApiMessageId`. BTW, PIP-224 mainly solves two problems: 1. When a multi-topics consumer acknowledges a `MessageId` that is not a `TopicMessageId`, a `PulsarClientException.NotAllowedException` will be thrown in synchronous methods. The asynchronous methods should not throw an exception. 2. For a multi-topics consumer, support seeking with a `TopicMessageId`. PIP-224 is designed for application users to specify an associated topic name when using a `MessageId` in `seek` or `acknowledge` on a multi-topics consumer. PIP-229 is more like a refactoring to allow the experienced developers access the fields of `MessageIdData` via a standard interface. [1] https://github.com/apache/pulsar/issues/18616#issuecomment-1328609346 [2] https://lists.apache.org/thread/g8o0qtljllxnvck69dn36205xg5xr8cc Thanks, Yunze On Fri, Dec 16, 2022 at 8:50 PM 丛搏 <bog...@apache.org> wrote: > > Abstraction based on MessageIdData is a good solution. I don't have > any discussion context. Why don't we put the topic name in it? > > All I can think of is PulsarApiMessageId extend > TopicMessageId(PIP-224[1]) right? > > Thanks, > Bo > [1] https://github.com/apache/pulsar/issues/18616 > > Yunze Xu <y...@streamnative.io.invalid> 于2022年12月16日周五 15:59写道： > > > > Hi all, > > > > I've opened a PIP to discuss: https://github.com/apache/pulsar/issues/18950 > > > > Currently the `MessageId` interface is not friendly to developers of > > Pulsar core and ecosystems. There is no abstraction of the > > `MessageIdData` defined in `PulsarApi.proto`. > > > > This proposal aims at solving this problem and allows more loose type > > assertions when using `seek` and `acknowledge`. > > > > You can also see the demo for reference: > > https://github.com/BewareMyPower/pulsar/pull/11 > > > > (Sorry I forgot to add the [DISCUSS] prefix again in the previous > > email, let's continue the discussion here) > > > > Thanks, > > Yunze
