I would like to change the current regex_revalidate plugin behavior related to 
how it handles loading and retaining regex rules.

What I am proposing to do is to make it so that after a `traffic_ctl config 
reload` that only the rules listed in the regex_revalidate config file are 
running and active.

The way it currently works explicit plugin logging (or targeted debugging) must 
be enabled to know what the current rule state is.  I believe that the contents 
of the last loaded regex_revalidate file should be sufficient to describe the 
current regex_revalidate plugin state.

For current regex_revalidate the behavior is as follows for config file 
loading, only performed when the regex_revalidate config file timestamp has 
changed:

1. Any rules with unmodified expiration time continue as they are.
2. Any new rules are added to the list.
3. Any rules with a modified expiration time are treated as newly loaded rules 
(effective rule start time is reset).
4. *Any currently active rules not listed in the regex_revalidate config file 
continue as they are*

I would like to change the regex_revalidate plugin configuration such that only 
rules present in the config are potentially active.

So the new proposed rules would be as follows:

1. Any rules with unmodified expiration time continue as they are.
2. Any new rules are added to the list.
3. Any rules with modified expiration time are treated as newly loaded rules 
(effective rule start time is reset).
4. *Any currently active rules not listed in the regex_revalidate config file 
are removed*

Other possible things to discuss (slightly off topic):

I would also ask if we should consider changing behavior '3' so that 
modification of the expiration time does NOT reset the effective rule start 
time but only changes the expiration date.  The downside to this is that it 
would make it more difficult to "reset" the start time of any existing rules 
(it would require removing a rule, reloading, reading, reloading).

Someone on IRC was asking about invalidation of only a window of content.  
Something like that might make sense for this plugin although it would require 
a bit of work to define and document config file changes.

Thanks!
Brian Olsen

Reply via email to