-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Loren -- it's not a matter of "popularity" -- it's a matter of being horrendously difficult to support. Without somebody doing the work to profile this beforehand to see if it helps (in particular loading code from disk may be *slower* than what we do now), and without patches to implement the change anyway, no, this is unlikely to be implemented. (in other words: please don't make me look at that code ;) - --j. Loren Wilton writes: > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFC4+EqMJF5cimLx9ARAqfnAJ9CTZhaf14ZMeWcGqKZlSwve2GkZQCfdJdk 7P7QJKK2Tc+abWJDwX4cFIk= =bliK -----END PGP SIGNATURE-----
