On 2024/10/14 00:14:25 +0200, Kirill A. Korinsky <kirill@korins.ky> wrote:
> On Sun, 13 Oct 2024 23:43:48 +0200,
> Omar Polo <op@omarpolo.com> wrote:
> > 
> > We currently require to list all the options for `listen' in a single
> > line, so it's custom to see config like this:
> > 
> > 	listen on all tls \
> > 		pki mx.example.org \
> > 		pki mx.example.com \
> > 		auth <auth> \
> > 		filter "whatnot"
> > 
> > (or worse, all on a single physical line)
> > 
> > This has the annoying consequence of breaking comments, since they would
> > extend to the end of the (logical) line.  And it's also a bit ugly.
> > 
> > So, why don't allow for brances to group the options?  IMHO this reads
> > better and is easier to write/maintain for newbies as well as well as
> > for seasoned users:
> > 
> > 	listen on all {
> > 		tls # now with comments!
> > 		pki mx.example.org
> > 		pki mx.example.com
> > 		auth <auth>
> > 		filter "whatnot"
> > 	}
> > 
> > These will be optional, as well as the newlines between the options.
> >
> 
> I think that almost similar logic should be used values inside "..." because
> right now it looks a bit ugly:
> 
>     filter dnsbl proc-exec "filter-dnsbl -m \
>            domain1 \
>            domain2 \
>            domain3 \
>            domain4"
> 
> what do you think?

some time ago I was playing with the idea of turning the prox-exec to an
argv-style list of string, which would also avoid having to use system()
and could be fed directly to exec*(), but I haven't wrote any diff in
the end.

Anyway, I think that also

	filter dnsbl proc-exec {
		filter-dnsbl -m domain1 domain2
			domain3 domain4
	}

would be way nicer.  I can cook an initial diff to turn the words inside
{...} into a string, so no larger changes for now, in the next days.

P.S.: I was mostly testing the waters here, if this looks fine to y'all
I'd like to also introduce {...} for `action' as well in a similar
manner.