incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Date Fri, 29 Jan 2010 03:32:16 GMT
Hello all...

As discussed before, here is the current wiki text of the proposal for
Chatterbot, a lightweight framework for chat responders.  The proposal
is at

Interested in comments, feedback and participation.



- wiki text -


ChatterBot is a lightweight, multiprotocol framework and container for
chat responders.


ChatterBot is a framework for developing chat responders (applications
that respond to messages received via online chat) and a container for
deploying them. It is written in Java SE, and runs as a Java
application. Chat responders are built by extending a single class and
modifying a configuration file to reference the new class.
ChatterBot's focus is on the following characteristics:

- Small: The current framework consists of eight core classes.

- Standalone: ChatterBot does not require external servers to operate.

- Portable: ChatterBot should work as run from any Java-capable
machine. For full functionality that machine should have internet
access, but localhost and console connectivity are possible. It should
be possible to run multiple instances of ChatterBot on the same
machine or on separate machines with no loss of functionality.

- Extensible: An instance of ChatterBot can support multiple message
parsers and protocols. Adding more is done by editing a configuration

- Dynamic: Activating and de-activating modules should be possible
during runtime.
Multi-user access: Multiple users, over multiple protocols, should be
able to access deployed applications.


A chat responder can serve as a user interface to applications, either
those built into the responder or external applications with which the
responder communicates. Such an interface is more secure than
interfaces such as Telnet or web services since it does not require
open ports in the firewall; the container connects out through the
firewall to the chat server, rather than allowing users to connect in.

A lightweight chat responder can be installed on any system to allow
command-line access to users over whatever protocol a user may have
access to. Thus applications can be accessed from web interfaces,
instant-message systems, text messages, email, etc. A scalable
container can allow as many or as few access protocols as are desired.

ChatterBot, therefore, has value for those circumstances where a user
interface is needed but a server-based or enterprise solution is
either not possible or not desired. It also can serve as a bridge
between applications, where one or more uses a chat protocol such as
XMPP to communicate.


ChatterBot began in 2005 as a thin-server approach to online
multi-user board games, implemented as applets sending gamestate
changes to one another via message relaying. The idea was to make as
general-purpose a server as possible, so that multiple games could be
built that employed the same message-relaying system.

Version 0.2 of the server was then refined in 2008 to allow for more
varied and functional message-handlers, and was used to implement a
room system that allowed for room-specific applications -- parsers
that checked the user's room before handling a command and sent
responses to other room occupants. This version was structured
entirely around XMPP. The global namespace was introduced to allow
modules to communicate with relatively limited coupling.

The current version, 0.3, as of late 2009, functions with XMPP and has
the capacity to function with whatever other protocols channels are
coded for. Applications built using 0.2 are being ported to 0.3. At
this point the original thin-server backend intended in 0.1 would be
built as an application using 0.3.

Current Status


Peer review and alternate ideas are welcomed in this project with open
arms. This project was intended specifically as an alternative to
traditional server-based or enterprise architecture; however, it is
recognized that tried-and-tested principles established in enterprise
architecture may be applicable here.

Core Developers

As of late 2009, there is one developer, Donald Whytock (dwhytock at
gmail dot com). Donald Whytock has several years of experience as a
software developer, working in a variety of languages, including C,
Java, Perl, PHP, JavaScript and SQL. He develops both professionally
and casually; ChatterBot has been an independent, voluntary effort.


ChatterBot's primary potential alignment with ASF is that of a
framework for internet-accessible applications. At its core, it is
largely free of outside dependencies, though modules can be built to
utilize other technologies. Embedded Derby is used in one application;
use of Derby and/or ORM should be explored as a base capability.

Initial Goals

ChatterBot currently exists as a functioning prototype; protocol
modules built for it provide access to chat responders via
XMPP/Jabber, localhost connections and a chat-simulating console.
Further development is to consist of refinement of the core classes
and expansion of the secondary modules.

Core Classes

Shell: The main-method class, used to launch the application.
Potential refinements: re-entrance, clean shutdown, restart

Listable: The foundation class for the global namespace.
Potential refinements: configuration file format, persistence

Module: The interface for all modules loaded by Shell.
Potential refinements: restart, shutdown

Channel: The interface for protocol handlers that accept incoming and
outgoing messages.
Potential refinements: an interface for relaying XML/HTML data within messages

Listener: The driving module that routes messages to Parsers.
Maintains a list of Parsers, submitting an incoming message to each
Parser in turn until a Parser indicates successful handling.

Parser: The abstract class for message-parsing modules.
Potential refinements: built-in parsing/tokenization, persistence

Sender: The module that routes outbound messages from Parsers to Channels.
Potential refinements: time-delayed messages, in-system messages

Secondary Modules

XMPPChannel: Extends Channel; protocol handler for XMPP.

LocalhostChannel: Extends Channel; handler for localhost connections
with other processes.

ConsoleChannel: Extends Channel; supplies a simple Swing console for
entering messages and receiving responses.

INIParser: Extends Parser, allows examination and manipulation of the
global namespace.

New modules should be developed to add optional functionality. In
particular, new Channels should be developed for AIM, YM, MSN, etc.
Other potential modules include:

SystemParser: Extends Parser, allows dynamic activation and
de-activation of modules.

FileXferParser: Extends Parser; implements file transfer between
client and ChatterBot's host. Will require refinement of Channel and
protocol-specific extensions of Channel.

DB: A database interface. One application built using ChatterBot
currently uses embedded Derby as its interface, preserving server

RoomParser: Extends Parser; implements chatrooms, relaying messages
among users in a room and allowing room-specific applications.

Known Risks

Orphaned Products

Currently the project has only one committer, though Donald Whytock
has been working on the code for a few years and is committed to
seeing a functional product available.

Inexperience with Open Source

While the developer has experience working with open-source products,
this is the first time opening up a project for open-source
collaboration. As modular as the project is, however, open-source
collaboration should not be a problem. It is greatly desired that this
project not be developed in a vacuum.

Fascination with the Apache Brand

Association with the Apache brand is not sought for personal
publicity; rather, it is sought for the associated community and
access to collaboration and peer review. This project will see its
full potential through public use and refinement, and a product more
refined for everyone's use is a more refined product for the
developer's use as well.

Initial Source

Original code developed by Donald Whytock.

Required Resources

Mailing Lists


Subversion Directory

Issue Tracking

JIRA ChatterBot

Initial Committers

Donald Whytock (dwhytock at gmail dot com)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message