incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Date Mon, 01 Feb 2010 18:39:48 GMT
I had originally thought that Felix Shell would replace Chatterbot
Listener, but I no longer think so.  Felix Shell, as far as I can
tell, is focused around Commands that have single outputs directed
toward their originator; Chatterbot Parsers, in a multiuser
environment, might have multiple outputs, and therefore have to
respond in the context of the originator. (v0.2 had writeMsg(target,
message) as well as writeMsgToAllBut(target, message).)  On the other
hand, I can see a Parser that acts like a Remote Shell.

So at this point we're talking about changing the proposal to focus on:

- Building Chatterbot around Felix as a modularity framework, with its
lifecycle management, its ServiceEvents to resolve dependencies, and
its Service properties to cut down on global datastore space.

- Building protocol handlers around a more general-purpose interface,
so that they can be used elseproject, then wrapping bundles around
them to make them standard services in a Felix environment for

I think Listener and Sender have to remain, rebuilt as services.
Changes to make Parser a service should leave the parse() method
functionally unchanged.

The global datastore (I call it the "namespace" in the proposal; I see
now that that conflicts with a term of art) would work best as a
service.  I'd like to discuss the Chatterbot Listable class vs. the
standard Dictionary or HashTable classes; Listable allows access to
subsets of the datastore by using a partial key.

So where do I go from here?  A new proposal draft?


On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <> wrote:
> On 1/29/10 10:38, Donald Whytock wrote:
>> I have an overview of the current Chatterbot architecture at
>> Chatterbot is different from JMS inasmuch as it's currently built to
>> receive messages from chat IDs and turn them into messages from
>> Chatterbot-internal IDs, and vice versa.  My intent was to allow
>> multiple chat IDs (same protocol or different protocols) to translate
>> into a single Chatterbot ID, so that a user could choose how he
>> accessed the bot.  Which protocol a message comes in over should be
>> totally transparent to the Parsers, and the Parsers should be able to
>> send messages out using Chatterbot IDs and not worry what protocol is
>> used to deliver them.
>> Looking briefly over Felix (, I'd say the
>> Chatterbot Listener and Parsers would be equivalent to the Felix Shell
>> and Commands, if the Shell was fed a JMS stream consolidated from
>> multiple message streams, and if its output was then dispersed over
>> multple message streams.  Though there would also need to be a way to
>> set up a Command to respond to any input string, rather than one
>> starting with a particular word.
> Just to be clear, there are two shells at Felix:
> And
> Although they basically do the same thing, I think Christopher was referring
> to the latter shell, which is more sophisticated than the former and may
> eventually become and OSGi standard.
> -> richard
>> Chatterbot Parsers also have the capacity to originate messages to
>> users other than the one whose message the Parsers are responding to,
>> so that they can serve as chatrooms; this would be the equivalent of
>> Felix sending out notifications to other users when a given user
>> performed a command.  Would this compare to Felix Event Admin?
>> That pretty much just leaves the global namespace, which is
>> essentially volatile JDO.  This is where the Chatterbot IDs are stored
>> and the Modules are defined; it gets updated by Channels, and can be
>> referenced and updated by Parsers.  I've implemented that as a TreeSet
>> of TreeSets, due to the key structure, but of course the internal
>> structure of the namespace is largely transparent to the modules.
>> So all in all I'd say there's no inherent barrier to building
>> Chatterbot with Felix.  Especially if it'll still run off my USB
>> drive.
>> Don
>> On Fri, Jan 29, 2010 at 3:44 AM, Christopher Brind<>
>>  wrote:
>>> Hi,
>>> I have read through the proposal and I like the idea of it.
>>> The only issues I have are around modularity and shell/console.  Apache
>>> already has a modularity solution (Felix) based on an open standard
>>> (OSGi) I
>>> don't think the Java community as a whole needs yet another modularity
>>> solution. =)   Felix also provides a shell which allows you to manage
>>> module
>>> (bundle) lifecycle (install, start, stop, update, uninstall) and while I
>>> don't know what the status is regarding the 'Standard Shell' (OSGi RFC
>>> 132)
>>> it is quite easy to add new commands to the Felix shell.   Felix is also
>>> very lightweight, so it wouldn't add much to your footprint, but would
>>> give
>>> you a sophisticated dynamic module contain in which to work as well as
>>> making it compatible with various environments already using OSGi now
>>> (e.g.
>>> Application Servers, etc).
>>> I could see potential uses for this project in my own work, but as I've
>>> implied, it would have to be compatible with OSGi which is where I spend
>>> most of my time.  I'd even offer to assist that effort on this project.
>>> This is more of a question, is there any Java API standard abstraction
>>> for
>>> chat protocols?  e.g.  I don't think there is but there is of
>>> course JMS, is ChatterBot significantly different from JMS?  If so,
>>> perhaps
>>> a low priority side goal of the project should be to develop a standard
>>> Java
>>> API standardisation for chat?
>>> Cheers,
>>> Chris
>>> On 29 January 2010 03:32, Donald Whytock<>  wrote:
>>>> 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.
>>>> Thanks...
>>>> Don
>>>> - wiki text -
>>>> Abstract
>>>> ChatterBot is a lightweight, multiprotocol framework and container for
>>>> chat responders.
>>>> Proposal
>>>> 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
>>>> file.
>>>> - 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.
>>>> Rationale
>>>> 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.
>>>> Background
>>>> 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
>>>> Meritocracy
>>>> 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.
>>>> Alignment
>>>> 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
>>>> non-dependence.
>>>> 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
>>>> chatterbot-private
>>>> chatterbot-dev
>>>> Subversion Directory
>>>> Issue Tracking
>>>> JIRA ChatterBot
>>>> Initial Committers
>>>> Donald Whytock (dwhytock at gmail dot com)
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message