>>>>> "DW" == Dave Wolfe <firstname.lastname@example.org> writes:
DW> I guess I'm dense, because I don't see it. How would I bounce subscribe
DW> requests only for addresses *not* in the sps.mot.com or mcu.mot.com
DW> domains or when the requesting and subscribing address don't match?
Assuming that by "bounce" you mean "consult for approval":
Follow the rules in order, take the first match. If the addresses
mismatch, consult. Else if it's in those two domains, allow. Else
consult. This really is exactly how things work in an
if..elsif..elsif..else construct. The difference is that you can leave out
all of the actual perl because it's filed in implicitly.
DW> The speedup involved assembling the regex subroutines once, when they
DW> were submitted, instead of every time Mj reads the config files (i.e.
DW> translate the config file into Perl code instead of parsing it every
DW> time, which I assume you're already doing).
Well, sort of. I actually haven't written the guts of the config system;
supporting backwards compatibility was giving me indigestion. Right now
I'm finishing up supporting old-style config files using perl5 data
structures and other neat stuff. I'm trying to spend as little time on it,
and this is where any surviving 1.xx code will be (in greatly modified
As for storing these expressions, I'm not quite sure of how to do it. I
was just planning to store the table and reparse it on each config file
read as a first pass, but since I haven't written it yet it doesn't much
matter. I will admit to being out of my league, or at least needing major
thought, when it comes to this area, so anything useful will help greatly.
DW> It could be done if what matched was reported instead of the regex that
DW> matched, which I think would be just as useful.
Well, take your pick. I think the only place that the actual matched
expression is made use of is in the report in the BOUNCE message. It would
probably do just as well to report the actual text. At this point I'm not
going to be choosy.