Components, Bots and related bits

Artur Bergman sky at
Sat Jul 8 17:20:18 UTC 2006

I do have objections, just emailed off two comments.

I fail to see why you want to expose the bot as you do, if you just  
insert it into the as the old bot did, it will be automatically  
handled by just writing to the jid. You are just re implementing the  
dispatch code.

I really don't like the distinction with two separate class  
hierarchies. They aren't really connected.


On Jul 8, 2006, at 10:06 AM, Martin Atkins wrote:

> 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:
> Bot
>     Eliza
>     Admin
> Component
>     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)
>         AIM
>         MSN
>         .....
>     MUC (Currently a plugin. Will turn into a component.)
>         IRC (A MUC interface to an IRC server? Maybe.)
> Plugin
>     Bot (exposes a bot as a node under a vhost)
>     Component (exposes a component as a subdomain of a vhost)
> Delivery
>     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