varnishd command line syntax for pluggable acceptors?

[nigoroll]

Working on a continuation of #3976 the question arose which command line syntax we want for pluggable acceptors. I see two basic options:

• backwards compatible -a

  -a [name=][kind,][listen_address[,PROTO|,option=value,...]]

here, kind would be the acceptor kind, so a valid use case would be -a foo=tcp,127.0.0.1:4444

• new, additional argument, for example -A, where kind is mandatory

  -a [name=]kind[,listen_address[,PROTO|,option=value,...]]

I like to avoid adding new options, but the first option comes with some ambiguity:

foo,bar

could mean

kind=foo, listen_address=bar

or

listen_address=foo, PROTO=bar

and, because of backwards compatibility, the error message might be confusing:

$ /tmp/sbin/varnishd -a foo=xxx,@foo -b @A -n /tmp/t
Error: Unknown protocol '@foo'

This can be tried out here: nigoroll@fe32476

[nigoroll]

bugwash: phk is for not adding -a processing for VEXTs. He suggests a varnish.cf file which would allow for per-extension acceptors (which I appreciate!) and we would probably also need some -Eext.so,-a=...,-a=... or similar.

I still think that using -E to load extensions and then use a consistent -a and -s across all implementations is cleaner and would still prefer that.

[nigoroll]

I've settled on suggesting

[name=][%<kind>,][listen_address[,PROTO|,option=value,...]]

now. Reasons:

• % is never the first character of a valid hostname for listen_address
• % is highly unlikely as the first character of a unix domain socket
• and if it is really intended as such, %uds,%path can be used

I did look at other alternatives, such as:

• [name=][kind=<kind>,][listen_address[,PROTO|,option=value,...]] is ambiguous again
• [name=][listen_address[,PROTO|,option=value,...]][,kind=<kind>] is bad because the option part should belong to the implementation

The implementation has been added to #4172 because plugging an acceptor is the basis for the test of this option.