The queuehandler sends messages to the user. If the user replies, the
messages are typically sent directly to the queuehandler (including
resource), not the default bot JID.
We add a little code for the xmppqueuehandler to periodically service
its queue of received messages. Received messages are forwarded to the
listener to deal with. We use XEP 33, 'addresses', to note the
original sender.
The xmppdaemon checks to see if the 'from' on a message is the daemon
address. If so, it looks for a XEP 33 'addresses' stanza, with an
'ofrom' address, which shows who it was originally is from.
This should let us send from one resource ID and still process
incoming messages in a different connection.
darcs-hash:20080830040717-84dde-59c75bfb107a1dd5fd531106751b4544bfd15656.gz
Add another queue handler for the public stream. Should further
parallelize the work of sending out messages.
darcs-hash:20080829181702-84dde-594505aa73d2380b13bd98917b70b02bac597d12.gz
Eventually, the poor xmppdaemon has become overloaded with extra
tasks. So, I've broken it up. Now, we have 5 background scripts, and
more coming:
* xmppdaemon.php - handles incoming XMPP messages only.
* xmppqueuehandler.php - sends notices from the queue out through XMPP.
* smsqueuehandler.php - sends notices from the queue out over SMS
* ombqueuehandler.php - sends notices from the queue out over OMB
* xmppconfirmhandler.php - sends confirmation requests out over XMPP.
This is in addition to maildaemon.php, which takes incoming messages.
None of these are "true" daemons -- they don't daemonize themselves
automatically. Use nohup or another tool to background them. monit can
also be useful to keep them running.
At some point, these might become fork()'ing daemons, able to handle
more than one notice at a time. For now, I'm just running multiple
instances, hoping they don't interfere.
darcs-hash:20080827205407-84dde-97884a12f5f4e54c93bc785bd280683d1ee7e749.gz
