You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Damian Meden <dm...@apache.org> on 2023/04/11 11:08:25 UTC
Proposed new TS API function: TSYAMLCompatibilityCheck()
const char* TS_YAML_CPP_CORE_VERSION;
int TS_YAML_CPP_CORE_VERSION_LEN;
TSReturnCode TSYAMLCompatibilityCheck(const char *yamlcpp_lib_version, int
yamlcpp_lib_len);
This will be handy for several reasons:
1 - Avoid binary compatibility issues: Make sure that any plugin using a TS
API with a TSYaml as part of their signature runs the same YAML-CPP version
as core.
2 - if any JSONRPC Plugin handler wants to make sure they have the same
yaml version as in core(before registering by TSRPCRegister, or even after
using the constants).
Draft PR <https://github.com/apache/trafficserver/pull/9598> available
Regards,
Damian.
Yahoo
Re: Proposed new TS API function: TSYAMLCompatibilityCheck()
Posted by Leif Hedstrom <zw...@apache.org>.
Hmmm, I’m not sure about this. Two reasons
1. We have compatibility checks already for plugins, and whatever yaml versions we have wi5 in a major version ought to always be compatible. If a plug-in uses TSYAML APIs, its compatibility ought to be guaranteed with the major version of ATS. This would also apply to libswoc, and I don’t think we should have an API for each of these library dependencies.
2. The version check that’s in here seem much too narrow, requiring an identical version match. This would mean that even if we do a small security fix for libyaml, which is compatible within the major version of ATS, any plugin using these APIs would need to be recompiled. This could cause patch and security releases to be incompatible, which we promised should not happen.
I would prefer that compatibility checks for any library dependencies that we include in our code stays within the existing version checks that plug-ins should already do. I think this would apply to both libyaml and libswoc, and singling out each library seems awkward. If that’s not possible, we should at least figure out how we relax the version check such that compatible minor version checks do not trigger a failure.
As an alternative, maybe we should add a generic library version dependency API, which can return something saying which library is not compatible, or if the core is not compatible etc. We can then add future additions without new APIs being added. It would still need to solve issue #2, with range checking of the versions for each dependency the API checks.
Thanks,
— Leif
> On Apr 11, 2023, at 05:09, Damian Meden <dm...@apache.org> wrote:
>
> const char* TS_YAML_CPP_CORE_VERSION;
>
> int TS_YAML_CPP_CORE_VERSION_LEN;
>
> TSReturnCode TSYAMLCompatibilityCheck(const char *yamlcpp_lib_version, int
> yamlcpp_lib_len);
>
>
> This will be handy for several reasons:
>
> 1 - Avoid binary compatibility issues: Make sure that any plugin using a TS
> API with a TSYaml as part of their signature runs the same YAML-CPP version
> as core.
> 2 - if any JSONRPC Plugin handler wants to make sure they have the same
> yaml version as in core(before registering by TSRPCRegister, or even after
> using the constants).
>
> Draft PR <https://github.com/apache/trafficserver/pull/9598> available
>
> Regards,
> Damian.
> Yahoo
Re: Proposed new TS API function: TSYAMLCompatibilityCheck()
Posted by Leif Hedstrom <zw...@apache.org>.
Hmmm, I’m not sure about this. Two reasons
1. We have compatibility checks already for plugins, and whatever yaml versions we have wi5 in a major version ought to always be compatible. If a plug-in uses TSYAML APIs, its compatibility ought to be guaranteed with the major version of ATS. This would also apply to libswoc, and I don’t think we should have an API for each of these library dependencies.
2. The version check that’s in here seem much too narrow, requiring an identical version match. This would mean that even if we do a small security fix for libyaml, which is compatible within the major version of ATS, any plugin using these APIs would need to be recompiled. This could cause patch and security releases to be incompatible, which we promised should not happen.
I would prefer that compatibility checks for any library dependencies that we include in our code stays within the existing version checks that plug-ins should already do. I think this would apply to both libyaml and libswoc, and singling out each library seems awkward. If that’s not possible, we should at least figure out how we relax the version check such that compatible minor version checks do not trigger a failure.
As an alternative, maybe we should add a generic library version dependency API, which can return something saying which library is not compatible, or if the core is not compatible etc. We can then add future additions without new APIs being added. It would still need to solve issue #2, with range checking of the versions for each dependency the API checks.
Thanks,
— Leif
> On Apr 11, 2023, at 05:09, Damian Meden <dm...@apache.org> wrote:
>
> const char* TS_YAML_CPP_CORE_VERSION;
>
> int TS_YAML_CPP_CORE_VERSION_LEN;
>
> TSReturnCode TSYAMLCompatibilityCheck(const char *yamlcpp_lib_version, int
> yamlcpp_lib_len);
>
>
> This will be handy for several reasons:
>
> 1 - Avoid binary compatibility issues: Make sure that any plugin using a TS
> API with a TSYaml as part of their signature runs the same YAML-CPP version
> as core.
> 2 - if any JSONRPC Plugin handler wants to make sure they have the same
> yaml version as in core(before registering by TSRPCRegister, or even after
> using the constants).
>
> Draft PR <https://github.com/apache/trafficserver/pull/9598> available
>
> Regards,
> Damian.
> Yahoo