Thanks for driving this improvement, ZengXiong. I second ZhangJian's comments. We don't want to break the existing API (forward compatibility) unless there are strong technical reasons that the user needs to do minor updates in the client to migrate to a new version.
-Lari On 2024/09/29 01:51:51 ZhangJian He wrote: > +1(no-binding) for this feature, it's common to pass tls.Config in the > Golang ecosystem(For example, current tlsOptions doesn't allow to pass > cert from memory bytes, but it's very common in golang). I tend to > proposal2, for backward compatibility, I think we can provide some > utility method to convert tlsOptions to tls.config. > > Thanks > ZhangJian He > > On Sun, Sep 29, 2024 at 6:03 AM 匡增雄 <lookup...@163.com> wrote: > > > > > > > > Hi all > > > > > > I would like to start a discussion to pass the std tlsconfig to pulsar go > > client. I have two options for change. > > > > > > > > Proposal 1: Incorporate std tlsconfig as an Externally Configurable > > Variable in tlsOptions > > > > In this proposal, I suggest adding the standard library's tlsconfig as an > > optional, externally configurable variable within tlsOptions. If > > StdTlsconfig is provided and not null, it would take precedence over the > > default settings. This approach ensures compatibility with existing > > implementations. It addresses scenarios where the current parameters are > > not sufficient, such as in private cloud environments where servers might > > lack domain names, necessitating the ability to bypass domain validation or > > to implement custom validation logic. Additionally, allowing tlsconfig to > > be passed as a parameter aligns with common practices in many Go SDKs. > > > > https://github.com/apache/pulsar-client-go/pull/1293 > > > > Proposal 2: Replace tlsOptions with std tlsconfig > > > > The second proposal is more radical, suggesting a complete replacement of > > tlsOptions with the standard library's tlsconfig. While this would result > > in a more elegant codebase, it would also entail significant changes to the > > code and potentially introduce incompatibilities. > > > > > > > > Thanks > > ZengXiong Kuang > > > > > > | | > > ZengXiong kuang > > | > > | > > lookup...@163.com > > | > > >
