In my investigation to see if we could re-use the {watchdog} table for logging instead of the {bad_behavior_log} I've come to the conclusion that its just not possible. Plus, there are other functions in BadBehavior which are either not-cross-db compatible, or are just not very good for large-scale sites.
What I'm thinking is possibly helping the BadBehavior maintainer rewrite the code using PHP classes and interfaces so that functions or specific functionality could easily be swapped out on different systems. This might be something better for the D7 version since it requires PHP 5.2, which has much better support for OOP than PHP 5/4.
Since we'd be modifying a large amount of the GPL'd BadBehavior code, we'd the include it in the module directly and not have to require people download it separately.
Comments
Comment #1
dave reidI e-mailed the BB creator (Michael) to see what his thoughts about converting BB into OOP-based code so that that other implementation plugins could override or change things as they needed to.
Comment #2
error commentedWith everything Bad Behavior related, please keep in mind that it is a multiplatform solution; anything that is specific to Drupal or any other platform must ideally be isolated and provided to the core through a standardized interface. Currently Bad Behavior uses a number of callback functions to access various functionality on the host platform.
In the current development branch of Bad Behavior I'm intending to pull all the existing database code out of the BB core and move it into the platform connectors (WordPress plugin, Drupal module, MediaWiki extension, etc). It never should have been there in the first place, but it was expedient. So this idea would be just about perfect.
I experimented a while back with making Bad Behavior's core a class, but it became unwieldy and much slower than I would like. So I'm probably not going to go this direction again any time soon; among other things Bad Behavior is intended to be fast. I would very much like it if the Drupal module were also fast.
With respect to logging, this is outside my scope. I don't much care where in Drupal you store the logs, just so long as I can make the callback and be sure that the logging actually occurs. In the future the BB core will also want to search through the log, so I am going to need to have a callback for this. Ideas would be appreciated.
Anything in the core that isn't cross-DB compatible needs to be rewritten or removed. Please bring these to my attention.
Comment #3
dave reid@error: Hey very glad to have your feedback here. I'd love to work with you to help make things better not just for the Drupal integration, but for all the plugins. Yeah the biggest thing I'm running into is the database code. If I wanted to change the db column names or change the date to use a UNIX timestamp, it's either ugly string replacements or not possible with the current code.
Things like getting the current IP address could be swapped since we have functions like ip_address() in Drupal that might be more robust that the default function in the Bad Behavior class.
I totally get that you want to keep it fast. That's one of the primary reasons Drupal has avoided OOP as long as possible. But things like our Database layer needing to work differently on engines is just not possible any other way.
Comment #4
dave reidI'm still working through exactly how to replicate the execution of the current script, but here's my progress so far. Includes a basic DrupalBadBehavior implementation that shows how we could override some of the methods in the base BadBehavior class. Still very much a work in progress...
Comment #5
gregarios commented