A few days ago I raised this issue with the Troll module http://drupal.org/node/501738
Both Troll and Blacklist go the trouble of maintaining a list of IP addresses for the purposes of bans and such.
A couple modules I've made could greatly benefit from the idea of using blacklists of IPs from another module - but if these IPs already gain a default effect like being banned, then it's no good. Also if more than one module want to do this, or use it in conjunction with the default banning features, then you need the option of using categories and configuring each one seperately.
Would blacklist be up for the challenge? I wonder whether you and the troll guy can join forces to focus on different areas and then have the two modules work together. I know thats a big call, but well worth considering. It would add more flexibility and be able to bring features to a lot of other modules focused on community management.

Comments

snufkin’s picture

snufkin commented

The problem, and this was the inspirator for this module is that some lists are due to their structure very query unfriendly. For example in Drupal 5 the core drupal_is_denied query a) runs on every single pageload, b) can not be indexed. Once you have ~100 rules in there, it really shows.

Here the idea is that those rules that dont need to fire every time can be moved away from the core, and thus will be fired less frequently. In our site's case this is applicable for every single rule.

I don't really see the need for an API, because its not too difficult to maintain the masks, I would need to rely on a third party module for my core functinality, and would i happen to want to add extra fields either i wait until it gets applied to that API, or I would need to use JOINs (for a dataset I could handle in one table at all).

What would make sense to me however, is to have one module that handles all the access related stuff. The admin could simply select what stage the rule should kick in. Originally i wanted to have blacklist as part of troll, but i found it simpler to put the code into the repository first, and then work on a merger.

danielb’s picture

danielb commented
Status: Active » Closed (fixed)

Will continue in the other issue (linked in original post of this issue)