<div dir="ltr"><div dir="ltr"><div>Thank you for both of your answers!</div><div><br></div><div>On 25.04.22 11:12, Poul-Henning Kamp wrote:</div><div>> The problem with VFP_Push() is that you cannot control the order in<br>
> any usable way, whereas editing the filter_list gives you full control.</div><div><br></div><div>The theoretical issue I have with this is that to use filter_list, I need to register the filter, which opens it to be used by VCL writers, even though the vmod should be the only one fiddling with it (notably because it must be the first in line, and only after some internal setup happened).</div><div><br></div><div>On Mon, Apr 25, 2022 at 3:03 AM Nils Goroll <<a href="mailto:slink@schokola.de">slink@schokola.de</a>> wrote:</div><div>> As pesi is so tightly coupled to core code, and, consequently is a "VARNISHSRC"<br>
> vmod, that I do not care about API boundaries,</div><div><br></div><div>That's convenient :-) I'm probably going to do the same. The slight annoyance in my case is that I have to decide whether to expose VFP_Push (and possibly others) in the rust bindings (breaking the API barrier way upstream), or if I just let vmods declare the bindings themselves downstream. <br></div><div>At the moment I don't care because I own the bindings and all the rust vmods I know of, but it may change at some point (and we can wait until them until exploring this again).</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div></div></div></div>