Hi Dridi! On Mon, May 12, 2025 at 09:55:51AM +0000, Dridi Boukelmoune wrote: > Hello Willy, > > > We do indeed have out own H3/QUIC implementation, but it's independent > > on vtest. For us, vtest is a totally standalone tool. We simply update > > it from time to time. Also it totally makes sense to me to use ngtcp2 > > and nghttp3 for vtest, because these libs are widely used and generally > > considered as a reference implementation, something that vtest would > > definitely benefit from. > > How bad would it be on the haproxy side to maintain haproxy support in > a shared library? > > varnishtest -m libvtc_haproxy.so ... > > The idea being that your library gets to register its specific > commands callbacks (haproxy, maybe others?) and rely otherwise on > built-in commands like client and server.
I see. Honestly I have no idea. I should discuss this with other devs. It's possible that for certain things it would ease the implementation of new features, but my concern is that while at the moment vtest is just a rolling release with no version, as soon as you start to expose some compatibility layer for external libs, you're necessarily forced to be a bit more careful not to break what's exposed so that external code continues to work. On the other hand I don't have the feeling that the current state of vtest makes it die under the pull requests, so probably that the overall effort can remain lower with the per-component support merged into it. Maybe we could have a mixed model: a mechanism to load external libs, with an incentive for getting stable code merged into the project to help it stay up to date with internal API evolutions. This way, fast moving projects could prefer to just rely on their external libs even if it means regularly rebasing, while reasonably stable ones might prefer to make sure that their support continues to work smoothly. Because I'm really convinced that ultimately what matters for testing is that it represents the least effort for *everyone*. Willy _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
