Hi Zike and Michael,
I agree that we can move this method to `ClientBuilderImpl`. Generally
users should not set this description, the client version string is
used to identify a specific implementation of the Pulsar API. If there
is a strong demand to configure the description for the API layer
(
> I'd rather use the "description" term, which indicates the
client version has extra description in addition to the client version
string.
The `description` term and 64 length limit all make sense to me.
> Is there any way we can avoid giving regular users easy access to this
field via the Clien
> I think we
> should consider putting a character limit on the field to prevent
> descriptions that are too long.
Good suggestion. A long description string is unnecessary and could be
used as malicious code. What do you think of limiting the length to
64? I think it's long enough.
Thanks,
Yunz
Great discussion. Derivative clients are an important consideration
for our discussion around capturing the version information.
Is there any way we can avoid giving regular users easy access to this
field via the ClientBuilder while still letting libraries add their
own suffix? We cannot prevent
I've updated this proposal to retain the original client version
string. I'd rather use the "description" term, which indicates the
client version has extra description in addition to the client version
string.
Thanks,
Yunze
On Fri, Mar 10, 2023 at 10:11 AM Yunze Xu wrote:
>
> Hi Zike,
>
> Good
Hi Zike,
Good suggestion. I agree with this approach. Maybe we can name it as
`subVersionString` to indicate that?
Thanks,
Yunze
On Thu, Mar 9, 2023 at 3:14 PM Zike Yang wrote:
>
> Hi Yunze,
>
> > I have changed this proposal to just add a config to `ClientBuilder`.
>
> I propose to add a field
Hi Yunze,
> I have changed this proposal to just add a config to `ClientBuilder`.
I propose to add a field named `clientVersionSuffix` rather than the
`clientVersion`. As I said before:
https://lists.apache.org/thread/g0128l85fkcmw4821188mjjznxbo4lhd
This is helpful for debugging. Especially for
Hi,
I have changed this proposal to just add a config to `ClientBuilder`.
And here is the demo implementation:
https://github.com/BewareMyPower/pulsar/pull/21/files
PTAL again.
Thanks,
Yunze
On Sat, Mar 4, 2023 at 10:39 PM Yunze Xu wrote:
>
> Hi Enrico,
>
> Thanks for your suggestion. It makes
Hi Enrico,
Thanks for your suggestion. It makes sense to me. I will think again
and modify this proposal.
Hi Tison,
I mentioned the C++ client because the initial motivation is to solve
the issue for the Python client and Node.js client. But after thinking
for a while, I believe it's more genera
I agree with Enrico that it's better to have a config option.
Also, we cannot simply replace the PulsarVersion call with the
DynamicPulsarVersion call because the client version string is now
constructed as:
String.format("Pulsar-Java-v%s", PulsarVersion.getVersion())
It's a config of client ver
Yunze,
Il Ven 3 Mar 2023, 12:31 Yunze Xu ha scritto:
> Hi all,
>
> Based on the previous discussion [1], I created a proposal to support
> configuring client version at SDK level:
> https://github.com/apache/pulsar/issues/19705
>
> I've added more explanations in the motivation part, let's use t
11 matches
Mail list logo
