Thinking about 4.1 softban/purges (yes, already...)

[Poul-Henning Kamp]

I'm starting to think about 4.1 and one of the first things that
pop up is the "softbans" and the purge ticket in #1139

I also noticed that we forgot to move the "purge" direct
action (ie: from vcl_hit{}) in 4.0 to VMOD.std.

Today a ban basically expires anything which it hits, but in
general that doesn't have to be the case, the ban mechanism
could be used to do any useful thing to the set of matching
objects, for instance extend the grace period by 10 minutes.

That's basically what "softbans" covers, the abilit to do something
like:
	ban -grace +10m req.url ~ [.]jpeg$

There are outstanding design issues with respect to specifying
the arguments, because of the "delayed action", those need to
be sorted out.

I want to do something similar for purge.

If you return(purge) from vcl_recv{}, the stuff's going to be
gone.

But I want to add a std.purge(ttl, grace, keep) where you can
modify all three as you like.

Both of these pressume that you can modify ttl/grace/keep on
an object and let it survive, and that's somewhat contrary
to our pre-4 decision to make objects read-only.

That decision in turn changes the previous calculus on where the
ttl|grace|keep timers live and I think they should move from obj
to objcore in 4.1.

That increases the size of objcore by 24 bytes or so, and since
it is magically 128 bytes right now I'm not happy about that,
but I think it will be worth the cost.

It also means adding a oc->method() so we can tell -spersistent
that we muked about with exp.*.

Comments ?

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