Components, Bots and related bits

Martin Atkins mart at
Sat Jul 8 17:06:05 UTC 2006

I just checked in the start of component support and some changes to the 
way bots work. Changesets here:

Since I've refactored Artur's bots code, I figured that I should 
probably explain myself a bit...

What I've tried to do is turn components and bots into abstract things 
that aren't tied to a particular caller. A component is a class that can 
process stanzas sent to a particular domain. A bot is a class that can 
process *messages* sent to a particular JID. Other than that, they 
really don't care where those messages come from and who is calling 
them. I've then provided a pair of plugins that serve the common case of 
exposing a component as a subdomain and a bots as a JID.

My main motivation for the bot refactoring was to make it easier to 
present a bot as a node under a component. You can see this in my 
example component, which presents an Eliza bot.

I'm heading towards a class heirarchy resembling the following:

     External (a JEP-0114 out-of-process component)
     Piped (an out-of-process component that just uses STDIN/OUT)
     Gateway (an abstract class for implementing IM gateways)
     MUC (Currently a plugin. Will turn into a component.)
         IRC (A MUC interface to an IRC server? Maybe.)
     Bot (exposes a bot as a node under a vhost)
     Component (exposes a component as a subdomain of a vhost)
     Component (Turns a vhost *into* a component? Maybe.)

...and so on.

I'm probably not going to write all of this stuff myself, but this is 
the goal I'm working towards unless anyone has any major objections. :)

I'd also like to expose a nicer API for components to talk to, but I've 
not really thought enough about what I mean by "nicer" yet.

More information about the Djabberd mailing list