--------
In message <e8975e99-3370-641f-362f-5841d38b912d@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.
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
phk@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
In message <e8975e99-3370-641f-362f-5841d38b912d@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.
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
phk@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