>
> As Penghui suggested, this field name is changed to `message_id` for
> potential generic usage. :)
>
> That's the thing - it's not really for potential generic use - it's more
for potential *internal* generic usage, which is publicly exposed.
When some outside visitor looks at the API and asks
Hi Asaf,
> (the field is not generic,
> it's specifically named shadow_message_id).
As Penghui suggested, this field name is changed to `message_id` for
potential generic usage. :)
> The second problem is clients: Every such field will eventually trickle
> down to the clients, which will need
Thanks for starting this proposal Asaf.
I'm trying to think more about this part today.
Currently, the public API protocol is defined in PulsarApi.proto [1]
And we have internal proto files such as MLDataFormats.proto [2],
SchemaRegistryFormat.proto [3], ResourceUsage.proto [4].
It looks like th
Hi,
We started discussing in PIP-180, which Penghui recommended I move to a
dedicated thread.
Pulsar has a public API in its binary protocol, which the clients use to
communicate with it. Nonetheless, it is its public API to the server.
I believe the public API should not be changed for internal
