On Sat, May 14, 2022 at 04:54:01PM +0200, Michael Storz wrote: > It would be best if these modifier functions could be registered by a > plugin and then used similarly to eval functions, which are also > registered and then used.
Tags are SpamAssassin core (PerMsgStatus) function. I always shun when I see proposal to "pluginize" something. It means creating more hooks and stuff that can break. The less public APIs/hooks we offer, the simpler it is for us to maintain into the future. Quoting you from recent post: "Recently the question was asked why Check.pm is a plugin if it is not optional. Check.pm is a plugin so that you can implement more than one check plugin." You can implement more than one check plugin? Do you realize what effort it would take to create your "own check plugin"? There's a bazillion things in PerMsgStatus etc that Check depends on and vice versa. It's almost impossible for anyone outside of SA developers to understand the internal dependencies and idiosyncrasies that have been piling up over the years. In the past there was developer talk for example about all rule types being plugins, yadda yadda. I agree that in IDEAL world everything would be pluginized and wildly customizable by anyone. That's just not reality with the resources the project has. For example a small little change somewhere can easily break sa-compile users, because that's pluginized and obscured away doing it's own thing with rules etc, yet all that is highly coupled into how PMS/Check internals work. All of the SpamAssassin test suite assumes that sa-compile is not used, it only has a single t/sa_compile.t which doesn't test much. > For a good and effizient use of lists a full rewrite of the WLBL.pm plugin > is needed. E.g. enlist_addrlist can be used for Mailchimp because the > customer id is a lowercase hex string, whereas the cid for Salesforce uses > lowercase and uppercase chars. Therefore we need lists where we can specify > the syntax of the list members. Addrlist should remain as (email/domain) addrlist and not be expanded into a generic [key/]value lookup store. Anything that is a large list, should be looked up from an external database (redis, sql, DNS etc). As a last resort a generic FileDB.pm could be provided that loads things into a memory hash. But I guess reading a file is few lines of code in a Plugin, so probably not needed. As long as it loads (and reloads?) the stuff pre-fork, so it doesn't waste memory.
