http://bugzilla.spamassassin.org/show_bug.cgi?id=3711
Summary: API change: Rename M::SA::read_scoreonly_config (and offsprings) Product: Spamassassin Version: SVN Trunk (Latest Devel Version) Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Libraries AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We've got this routine Mail::SpamAssassin::read_scoreonly_config which calls Mail::SpamAssassin::Conf::parse_scores_only which calls Mail::SpamAssassin::Conf::Parser::parse with $scoresonly=1 The POD for the first routine says "Read a configuration file and parse only scores from it." Which is incorrect as it doesn't read only scores but options which are allowed for mere users. I suggest that we do a simple search-and-replace on all variations of the scoresonly word so we get an API like this: Mail::SpamAssassin::read_user_cf (like ::read_cf) Mail::SpamAssassin::Conf::parse_user_file The same is true for the Mail::SpamAssassin::Conf::load_scoreonly_sql Mail::SpamAssassin::Conf::load_scoreonly_ldap routines. Any everywhere else where grep shows a string scoresonly or similar. Btw, what a crappy API is that? For each added config backend we need to add a bunch of routines to the main object and the caller actually has to remember always which backend is currently in use? Can we already deprecate those calls and replace it with a more sane way for 3.1? For 3.1 I want to move the ::read_cf and ::read_scoreonly_config logic into its own module Mail::SpamAssassin::Conf::File and Mail::SpamAssassin::Conf::Dir anyway, so only the stubs would stay. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.