I think this sounds great!. As this change became a blocker for my current project, I ended up implementing the change. Patch sent to the -dev list.
In my patch I didn't implement any additional oc->method() for the exp changes, AFAICS the existing updatemeta() function suffices. Martin On 6 May 2014 23:45, Poul-Henning Kamp <[email protected]> wrote: > > 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 > [email protected] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > varnish-dev mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -- <http://varnish-software.com>*Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly!
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
