CLI command vmod.tell

[Poul-Henning Kamp]

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