create bot queue for website hook instances
| Project: | Bot |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
So, there's a fatal flaw, recently discovered by eddan, in the bot.module. It's so simple I never even thought of it: the hooks called during normal node creation via a web browser are *not* propagated to the unique instance of Drupal that is running the bot.module - they're just two entirely separate processes. They don't talk to each other. Thus, to fix this, here's a napkin design:
* bot_message() and bot_action() get _queue equivalents.
* These bot_message_queue() equivalents accept the same thing as their master.
* Instead of using the $irc object, they save their data to a database table.
* The IRC instance checks this table every five minutes (via irc_cron) and spits 'em out.
* All modules that want to integrate with Drupal's normal hooks would use the _queue equivalents.
#1
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.
#2
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.
#3
#4
Note to self: be sure to add docs to the README for this.
#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.
#6
Sorry, forgot to change the status.
#7
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.
#8
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.
#9
I'd much rather have something that is more Druplish. Talking to another process via a port is non-Druplish - the only way to make it non-Druplish would be middleman functions to hide all the port talking, at which point there's no real difference between ports and table queues.
#10
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.
#11
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.
#12
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.)