When changing purge->ban in 3.0, should we also expose the VRT_ban_string functionality from VCL instead of relying on magic parsing the difference

[Poul-Henning Kamp]

In message <BANLkTimfqcFQx2rwcrM6-CMaCosQ+6+Xtg at mail.gmail.com>, Martin Blix Gr
ydeland writes:

>This will produce a compiler error of missing expected operator, as the
>compiler recognizes the req.http.ban-expression as a variable and goes into
>the mode of recognizing ban-expressions (reads 3 arguments, first a
>variable, 2nd an operator and third a stringval, possibly followed by && and
>other triplets). If the first argument isn't a variable, it will feed a
>string to VRT_ban_string instead for parsing at runtime.

I'm not happy with the way this entire thing turned out.  It looked
quite sensible when I started out and then it got ugly on contact
with the reality.

I'm sort of hessitant to mandate the one-string format, because it
will force some people to collect into one string, components which
the BAN code will immediately split back into those components.

One possible, but ugly-ish solution, is to make the VCL::ban function
var-args, and let the number of args steer the interpretation:

	ban(req.http.ban-expression);	
	ban(req.http.foo, '==', req.http.ban-detail);

Not sure how much work that is to implement, if it is 3.0 material
or even a good idea.

-- 
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.