On Fri, May 18, 2018 at 11:30 AM, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote: > -------- > In message <e8975e99-3370-641f-362f-5841d38b9...@uplex.de>, Geoff Simmons > write > s: > >>> vmod.tell somevcl::somevmod "bla bla bla" > > I looked a bit at this. > > There is a hurt of locking issues for VMOD writers trying to do > anything smart, but trivial stuff like setting global options for > the VMOD etc, shouldn't cause trouble. > > VCC wise I think this will be a "$CLI" stanza, and the function > will get called with a VRT_CTX and a char **, and return an enum > VCLI_status_e.
Can we also pass a nonce to the VMOD? So that "global" actions can be skipped once done when a VMOD like xkey is targeted with a VCL pattern matching more than once. > I think I prefer this naming: > > vmod.tell [VCL_PATTERN:]VMODNAME arguments [...] > > The default VCL_PATTERN will be the active VCL. > > In other words: > > vmod.tell std bugger off > > only hits the std vmod in the active vcl, whereas > > vmod.tell *:std bugger off > > will hit the std vmod in all vcls which has imported it. > > When used without a pattern: > ---------------------------- > > If the active VCL has not imported a vmod of that name > status is CLIS_CANT. > > If that VMOD does not implement $CLI it will be CLIS_UNIMPL. > > Otherwise the VMODs $CLI determines the status. > > When used with a pattern: > ------------------------- > > If no VCLs are matched by pattern: CLIS_CANT > > If the VMOD is not loaded in any of the matched VCLs: CLIS_CANT > > If no hit VMOD implements $CLI: CLIS_UNIMPL. > > If any hit VMOD's $CLI returns non-200: new status CLIS_KABOOM (=202) > > Otherwise CLIS_OK > > Still waffling on: > ------------------ > > Should names of VCLs be put into cli output as subheadings when > pattern is used so VMODs won't have to do that, or should they > only be added in front of VMODs which produce cli output. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > varnish-dev mailing list > varnish-dev@varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev