Hi, Michael,
> I don't think we need to make it configurable because the library
owner, not the user, has full control when creating the Connect
command.
The Nodejs, Python, and C client are all based on the C++ client. Same
for the Scala client which is based on the Java client. They have no
con
> I think it makes sense to make the format
"pulsar--" for official clients. We could then
recommend third party clients replace "pulsar" with a relevant org
name. There isn't a way to enforce the version string though, so these
would only be recommendations.
+1 for this format.
> F#:
I'm not exa
> Go:
> ClientVersionString = "Pulsar Go " + Version
> https://github.com/apache/pulsar-client-go/blob/dedbdc45c63b06e6a12356785418cd906d6bab3c/pulsar/internal/version.go#L43
Because we filter out the official go client, I propose that we remove
the filtering of certain client versions:
https://gi
I found another data point in favor of moving in this direction. Our
protocol spec says the following about the client_version field:
message CommandConnect {
"client_version" : "Pulsar-Client-Java-v1.15.2",
"auth_method_name" : "my-authentication-plugin",
"auth_data" : "my-auth-data",
"protocol_v
> A better solution is that we could allow the
> user to specify the suffix of the client version.
I don't think we need to make it configurable because the library
owner, not the user, has full control when creating the Connect
command.
We can update our protocol spec to recommend appropriate us
> But I'm wondering if it's possible to support configuring the client
version string by users?
I think it's possible. A better solution is that we could allow the
user to specify the suffix of the client version. For example, by
adding a new configuration like `clientVersionSuffix` to the
ClientC
+1 - I think this is a helpful change. We already do this in the Java
Admin http client when we set the user agent [0].
> But I'm wondering if it's possible to support configuring the client
> version string by users?
This is always the case because we support third party clients. In my
view, thi
+1
But I'm wondering if it's possible to support configuring the client
version string by users? For example, if users forked their own
client, they might want to differ the client version with the official
client. The disadvantage could be that users can configure any version
string as they want.
+1
Enrico
Il giorno mar 21 feb 2023 alle ore 10:23 Baodi Shi
ha scritto:
>
> +1, Good idea.
>
> Thanks,
> Baodi Shi
>
>
> 在 2023年2月21日 15:24:45 上，avinash kala 写道：
>
> > +1, sounds good.
> >
> > On Tue, Feb 21, 2023, 12:39 PM Zixuan Liu wrote:
> >
> > +1, good idea!
> >
> >
> > Thanks,
> >
> >
+1, Good idea.
Thanks,
Baodi Shi
在 2023年2月21日 15:24:45 上，avinash kala 写道：
> +1, sounds good.
>
> On Tue, Feb 21, 2023, 12:39 PM Zixuan Liu wrote:
>
> +1, good idea!
>
>
> Thanks,
>
> Zixuan
>
>
> Zike Yang 于2023年2月21日周二 11:33写道：
>
>
> > Hi, all
>
> >
>
> > Currently, the Pulsar broker uses
+1, sounds good.
On Tue, Feb 21, 2023, 12:39 PM Zixuan Liu wrote:
> +1, good idea!
>
> Thanks,
> Zixuan
>
> Zike Yang 于2023年2月21日周二 11:33写道：
>
> > Hi, all
> >
> > Currently, the Pulsar broker uses the field `client_version` to get
> > the version of the client. The client will send the client_v
+1, good idea!
Thanks,
Zixuan
Zike Yang 于2023年2月21日周二 11:33写道：
> Hi, all
>
> Currently, the Pulsar broker uses the field `client_version` to get
> the version of the client. The client will send the client_version to
> the broker through `CommandConnect` [0] during the connect or
> `CommandAuth
Hi, all
Currently, the Pulsar broker uses the field `client_version` to get
the version of the client. The client will send the client_version to
the broker through `CommandConnect` [0] during the connect or
`CommandAuthResponse ` [1] during the auth challenge. We could get the
client_version from
13 matches
Mail list logo
