I know user rules aren't real popular with the sa dev community, however
that attitude isn't universally shared by sa users.  Therefore may I
suggest:

Would it be possible when reorganizing things to come up with some
semi-persistant storage for compiled user rules, so that they don't have to
be rewritten and recompiled in a bunch of evals for every message processed
for the user?

At the very least it should be moderately trivial to save the text passed to
the evals into a file someplace, and then just eval that one file to get
everything compiled.  Timestamps would indicate if the pre-built stuff was
out of date or not.

Is there a way that they could be saved in a more-compiled state when used
with spamd and similar?  Maybe name the rules with the username as part of
the procedure name, and just add them to the namespace the first time
encountered?

If there were a way to make user rules be a subclass of the main rules, then
you could just call the user rules for each user, and any user rules (or I
presume scores) would override the standard rules, and anything that didn't
override would pass through to the main rules.

Of course this assumes "the rules" was a class instance of some sort of
other, and you could call ruleclass->dorules(message) or the like (however
that C++ invocation would be spelled in Perl).

Having all user rules remain in memory forever would certainly add some to
the bloat of SA memory usage. However, if one assumes most users would have
few rules compared to the number of overall system rules, then the increase
might be reasonable; especially since you would be trading off that memory
for the compile and build overhead on every message.

        Loren

BTW, if "the rules" were in a class, then it would be possible to create the
instance of that class at startup in just about exactly the same way user
rule subclasses could be created.  Then a hup, instead of taking spamd and
children down, would just cause the children to discard the current rules
instance and fabricate a new instance and continue onward.

Reply via email to