incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Date Fri, 29 Jan 2010 16:05:21 GMT
On 1/29/10 10:38, Donald Whytock wrote:
> I have an overview of the current Chatterbot architecture at
>
> http://www.imtower.net/chatterbot/doku.php?id=overview
>
> 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 (http://felix.apache.org), 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:

     http://felix.apache.org/site/apache-felix-shell.html

And

     http://felix.apache.org/site/apache-felix-gogo.html

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<brindy@brindy.org.uk>  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. javax.chat?  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<dwhytock@gmail.com>  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
>>>
>>> http://wiki.apache.org/incubator/ChatterbotProposal
>>>
>>> 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
>>>
>>> https://svn.apache.org/repos/asf/incubator/chatterbot
>>>
>>> Issue Tracking
>>>
>>> JIRA ChatterBot
>>>
>>> Initial Committers
>>>
>>> Donald Whytock (dwhytock at gmail dot com)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>        
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message