create bot queue for website hook instances

This is what I whipped up in a hurry. On module install it creates two tables to hold messages and actions (maybe it should be combined to only use one table, but I didn't bother) which are updated from "the website instance" of drupal. The IRC instance checks the table every 5 minutes and deletes the messages in the queue from the table as it sends it.

This is an initial version, code news review, but it works here so I'm happy with this for now.

Ah, that makes sense. Good find, eddan. I think this should be put in the Drupal 6 branch instead, and then backported to Drupal 5.

Here's a 6.x port. It's basically (but not exactly) the same as the 5.x version that was posted. (It uses one table instead of two, and has an extra column to decide whether it's an action or a message.

Sorry, forgot to change the status.

This patch is a slight modification to the one I submitted previously. Rather than checking for updates to the queue during the bot's cron run every five minutes, I've added a special callback that only checks the website's message queue, and does so every ten seconds. The reason for this is that if you have even a slow stream of messages entering the queue, the bot will attempt to send them all at once, and quite likely get booted from the channel. An example of this is a module that provides notices to an IRC channel when new content is posted. This would be a problem for busy sites.

From the sidelines: is it not possible to somehow use the running bot php to listen to a certain port, and talk to the bot via that? I imagined something along the lines of adding a socket listener to Net_SmartIRC, but that documentation is quite obscure, couldnt figure out if its possible.

I've been running this patch on my own IRC channel (#notsorandom) since I posted it, and it's been working great, but occasionally the IRC bot seems to momentarily lose connection with the server just after posting a message. It seems to happen when there's no other channel traffic. I suspect some issue with keep-alives with the IRC channel, but I haven't had the time to narrow it down.

[edit] To clarify, the bot seems to lose connection with the server when it posts a message to IRC amid an otherwise silent channel.

Yeah I feel its neither drupalish, or its being a long shot anyway. But I am feeling negative towards the pull based communication, running cron loops, when there is an active daemon (the bot php) running, that we could utilize somehow to push the content.

I've run into issues with PHP not being compiled with sockets before. If, for example, a website running on a shared web host that doesn't have sockets support compiled into PHP wants to run the bot on another server that does, they couldn't with the push-based sockets model. The only way to do it is polling an SQL database. (I've run into this issue with a similar project myself.)

Here is a re-roll and a bit of a rewrite. I cleaned up the .install, removed t() from the descriptions and added a few fields.

Also changed the bot_queue cron, its now a hook, so other modules can take charge of processing the entries.

I am not quite sure how much of the output processing should be integrated into bot.module itself though. I assumed that every module should implement its own queue handling mechanism, and bot.module itself will provide basic bot_message and bot_action (like totalmeltdown's patch suggests). But I added a module field into the table so upon insert modules could delegate queue parts to themselves.

Is there any module currently in bot core that should be included into this patch? For instance should bot_aggregator use this?

Sorry snufkin, any particular reason why that simple bot_message_queue($options) { drupal_write_record... } API function is not in bot module? otherwise each separate module providing irc messages will have to declare a very similar function to put records in that table, instead of tracking only their custom information.

Oh, I forgot to mention, we should provide an update function to create the table in previously installed bot instances, beside that, only the only concern is are the missing functions, IMO.