On Tue, May 30, 2023 at 10:09:55PM +0200, Aurelien DARRAGON wrote: > Dear haproxy users, > > We recently noticed an inconsistency with haproxy -dKcnv output (which > may be used to dump all available sample converters from the cli). > > Here is how a converter is currently being represented in -dKcnv output: > > conv_name([arg1 ...]) : output_type => input_type > > For instance with the iff converter this would look like this: > > > $> haproxy -f test.conf -dKcnv | grep nbsrv > > iif(string,string): str => bool > > > According to the documentation, iff converter returns a string, either > the first or the second argument, depending on whether the input value > (boolean expected) is true or false. > > Here is the catch: with the current output format, "=>" suggests a left > to right transition. Thus it feels more logical to see input => output > instead of output => input. > > Input and output were probably mixed when the feature was first > implemented and it was never updated since. > > We would like to know your thoughts about this, whether you would be OK > or not with us "inverting" output_type and input_type in -dKcnv output > to remove this ambiguity for the 2.8 release: > > conv_name([arg1 ...]) : input_type => output_type > > For the iff converter used as an example, this would result in the > following output being produced: > > > iif(string,string): bool => str > > As '-dKcnv' support was added in 2.6, we would totally understand if you > rely on the current output format and don't expect nor want it to be > changed, but we would prefer to hear it from you if this is the case.
Thanks Aurélien for the explanation. In short, I don't think anyone depends on it and I'm willing to merge Aurélien's fix today before the release. However if we get a single "please don't do that" before noon CEST today, I'll refrain from doing it. It won't change in a stable version in any case, so better know before releasing ;-) Thanks, Willy
