Components, Bots and related bits
Martin Atkins
mart at degeneration.co.uk
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:
<http://code.sixapart.com/trac/djabberd/changeset/550>
<http://code.sixapart.com/trac/djabberd/changeset/551>
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