You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Donald Whytock <dw...@gmail.com> on 2010/02/01 19:39:48 UTC
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
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
Chatterbot.
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?
Don
On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> 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<br...@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<dw...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, Mar 22, 2010 at 16:49, Donald Whytock <dw...@gmail.com> wrote:
> Okay, getting back into this. Offering to mentor? Have I your
> permission to add you to the proposal in that capacity?
Yep.
> I would not be averse to this project being attached to a bigger
> project. Did you have a particular one in mind?
Nope.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
Okay, getting back into this. Offering to mentor? Have I your
permission to add you to the proposal in that capacity?
I would not be averse to this project being attached to a bigger
project. Did you have a particular one in mind?
Don
On Fri, Mar 12, 2010 at 3:45 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Thu, Mar 11, 2010 at 22:23, Donald Whytock <dw...@gmail.com> wrote:
>> Sorry to leave things on a sour note...had family in from college.
>>
>> Do we want to take this off-channel to discuss details?
>
> Preferrably - no. Let's continue here.
>
> Bernd
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
On Thu, Mar 11, 2010 at 22:23, Donald Whytock <dw...@gmail.com> wrote:
> Sorry to leave things on a sour note...had family in from college.
>
> Do we want to take this off-channel to discuss details?
Preferrably - no. Let's continue here.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
Sorry to leave things on a sour note...had family in from college.
Do we want to take this off-channel to discuss details?
Don
On Wed, Mar 3, 2010 at 11:57 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Mar 3, 2010 at 16:23, Donald Whytock <dw...@gmail.com> wrote:
>> So I gather that's a "no" on mentoring.
>
> throws ParseException.
>
> In fact, I'm still volunteering to mentor (if you still want to have me).
> I only propose to think about and discuss to move it to an existing
> project's sandbox as an alternative to incubation.
>
> Bernd
>
>>
>> Any other takers?
>>
>> Don
>>
>> On Wed, Mar 3, 2010 at 3:36 AM, Bernd Fondermann
>> <be...@googlemail.com> wrote:
>>> On Wed, Mar 3, 2010 at 00:06, Donald Whytock <dw...@gmail.com> wrote:
>>>> On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann
>>>> <be...@googlemail.com> wrote:
>>>>> So, what are your short term goals with chatterbot? As you are on the
>>>>> incubator list and put up a proposal, the goal should be to become an
>>>>> Incubator project. Otherwise, we are just wasting time here.
>>>>> An important part of preparing for Incubation is recruting mentors.
>>>>
>>>> Making Chatterbot an Incubator project is indeed my goal. Based on
>>>> that goal, I looked at the other projects under consideration, which
>>>> typically have multiple committers, an existing community and a
>>>> good-sized codebase,
>>>
>>> Indeed, this is the tricky part.
>>> You might want to consider taking this project to the sandbox of an
>>> existing project, and grow from there.
>>>
>>>> and wondered what the response would be to, "Hi,
>>>> wanna be the mentor for my project that consists of me and my
>>>> eleven-class app?"
>>>
>>> Was that your question at the beginning?
>>>
>>>>
>>>> I'm pleased to find there is interest in the project. Yes, I am
>>>> looking for mentors.
>>>
>>>>
>>>>> If you'd want to test against a local server, I recommend using Vysper
>>>>> (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
>>>>
>>>> Thanks. I had a console for offline parser testing; this'll help with
>>>> offline channel development.
>>>
>>> Bernd
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 3, 2010 at 16:23, Donald Whytock <dw...@gmail.com> wrote:
> So I gather that's a "no" on mentoring.
throws ParseException.
In fact, I'm still volunteering to mentor (if you still want to have me).
I only propose to think about and discuss to move it to an existing
project's sandbox as an alternative to incubation.
Bernd
>
> Any other takers?
>
> Don
>
> On Wed, Mar 3, 2010 at 3:36 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Wed, Mar 3, 2010 at 00:06, Donald Whytock <dw...@gmail.com> wrote:
>>> On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann
>>> <be...@googlemail.com> wrote:
>>>> So, what are your short term goals with chatterbot? As you are on the
>>>> incubator list and put up a proposal, the goal should be to become an
>>>> Incubator project. Otherwise, we are just wasting time here.
>>>> An important part of preparing for Incubation is recruting mentors.
>>>
>>> Making Chatterbot an Incubator project is indeed my goal. Based on
>>> that goal, I looked at the other projects under consideration, which
>>> typically have multiple committers, an existing community and a
>>> good-sized codebase,
>>
>> Indeed, this is the tricky part.
>> You might want to consider taking this project to the sandbox of an
>> existing project, and grow from there.
>>
>>> and wondered what the response would be to, "Hi,
>>> wanna be the mentor for my project that consists of me and my
>>> eleven-class app?"
>>
>> Was that your question at the beginning?
>>
>>>
>>> I'm pleased to find there is interest in the project. Yes, I am
>>> looking for mentors.
>>
>>>
>>>> If you'd want to test against a local server, I recommend using Vysper
>>>> (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
>>>
>>> Thanks. I had a console for offline parser testing; this'll help with
>>> offline channel development.
>>
>> Bernd
>>
>> ---------------------------------------------------------------------
>> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
So I gather that's a "no" on mentoring.
Any other takers?
Don
On Wed, Mar 3, 2010 at 3:36 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Mar 3, 2010 at 00:06, Donald Whytock <dw...@gmail.com> wrote:
>> On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann
>> <be...@googlemail.com> wrote:
>>> So, what are your short term goals with chatterbot? As you are on the
>>> incubator list and put up a proposal, the goal should be to become an
>>> Incubator project. Otherwise, we are just wasting time here.
>>> An important part of preparing for Incubation is recruting mentors.
>>
>> Making Chatterbot an Incubator project is indeed my goal. Based on
>> that goal, I looked at the other projects under consideration, which
>> typically have multiple committers, an existing community and a
>> good-sized codebase,
>
> Indeed, this is the tricky part.
> You might want to consider taking this project to the sandbox of an
> existing project, and grow from there.
>
>> and wondered what the response would be to, "Hi,
>> wanna be the mentor for my project that consists of me and my
>> eleven-class app?"
>
> Was that your question at the beginning?
>
>>
>> I'm pleased to find there is interest in the project. Yes, I am
>> looking for mentors.
>
>>
>>> If you'd want to test against a local server, I recommend using Vysper
>>> (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
>>
>> Thanks. I had a console for offline parser testing; this'll help with
>> offline channel development.
>
> Bernd
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 3, 2010 at 00:06, Donald Whytock <dw...@gmail.com> wrote:
> On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> So, what are your short term goals with chatterbot? As you are on the
>> incubator list and put up a proposal, the goal should be to become an
>> Incubator project. Otherwise, we are just wasting time here.
>> An important part of preparing for Incubation is recruting mentors.
>
> Making Chatterbot an Incubator project is indeed my goal. Based on
> that goal, I looked at the other projects under consideration, which
> typically have multiple committers, an existing community and a
> good-sized codebase,
Indeed, this is the tricky part.
You might want to consider taking this project to the sandbox of an
existing project, and grow from there.
> and wondered what the response would be to, "Hi,
> wanna be the mentor for my project that consists of me and my
> eleven-class app?"
Was that your question at the beginning?
>
> I'm pleased to find there is interest in the project. Yes, I am
> looking for mentors.
>
>> If you'd want to test against a local server, I recommend using Vysper
>> (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
>
> Thanks. I had a console for offline parser testing; this'll help with
> offline channel development.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> So, what are your short term goals with chatterbot? As you are on the
> incubator list and put up a proposal, the goal should be to become an
> Incubator project. Otherwise, we are just wasting time here.
> An important part of preparing for Incubation is recruting mentors.
Making Chatterbot an Incubator project is indeed my goal. Based on
that goal, I looked at the other projects under consideration, which
typically have multiple committers, an existing community and a
good-sized codebase, and wondered what the response would be to, "Hi,
wanna be the mentor for my project that consists of me and my
eleven-class app?"
I'm pleased to find there is interest in the project. Yes, I am
looking for mentors.
> If you'd want to test against a local server, I recommend using Vysper
> (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
Thanks. I had a console for offline parser testing; this'll help with
offline channel development.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Mar 2, 2010 at 00:43, Donald Whytock <dw...@gmail.com> wrote:
> Well, it seemed presumptuous to ask about mentors when I hardly had a
> community...but thank you for your consideration. Yes, mentoring
> would be appreciated.
So, what are your short term goals with chatterbot? As you are on the
incubator list and put up a proposal, the goal should be to become an
Incubator project. Otherwise, we are just wasting time here.
An important part of preparing for Incubation is recruting mentors.
> I tested my XMPP handler against two servers: Google's chat server and
> one managed by dreamhost.com. The handler is rudimentary, yes; there
> are several functions of the protocol it doesn't handle yet. A big
> one is dynamically accepting/rejecting users; at the moment I manually
> authenticate new contacts.
>
> But it does work (mixed results with Google). V0.3 will make a
> connection to its server, accept messages from authenticated contacts
> and send responses. With the right Parsers it should communicate with
> multiple users, relaying messages between them and originating
> messages based on other users' actions. I have Parsers that did this
> for v0.2 that I haven't ported over yet.
>
> The handler was a first effort for me, meant as an education in
> protocol handling. Happy to look at other things now...Thanks, I'll
> check out Smack. (http://www.igniterealtime.org/projects/smack/)
If you'd want to test against a local server, I recommend using Vysper
(http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/).
Bernd
>
> Don
>
> On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> Hi,
>>
>> What about mentors? I cannot find any note you are actively searching
>> for them, but maybe I missed that.
>>
>> As I think about volunteering to mentor, my question is: Against what
>> server did you test your own XMPP implementation? Does it really work
>> as it seems to be rudimentary to me. Why didn't you use a XMPP client
>> lib like Smack?
>>
>> Thanks,
>>
>> Bernd
>>
>> On Mon, Mar 1, 2010 at 12:54, Donald Whytock <dw...@gmail.com> wrote:
>>> Hello again...
>>>
>>> Following is the revised proposal text, as posted on the wiki.
>>> Significant changes are the goals, which now focus on building the
>>> framework around Felix and devising a standard for protocol handlers
>>> to be used both inside and outside the project, and the committer
>>> list, which now includes Christopher Brind. The wiki copy is at
>>>
>>> http://wiki.apache.org/incubator/ChatterbotProposal
>>>
>>> Thanks...
>>>
>>> Don
>>>
>>> -----
>>>
>>> Proposal:
>>>
>>> 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.
>>>
>>> Version, 0.3, as of late 2009, functions with XMPP and has the
>>> capacity to function with whatever other protocols channels are coded
>>> for. V0.3, though, uses a custom shell, with rudimentary module
>>> lifecycle capability.
>>>
>>> This proposal introduces version 0.4, to be based on OSGi for module
>>> lifecycle management and event-driven module synchronization.
>>> Applications originally built for v0.2 will be ported to v0.4.
>>>
>>> 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. As command parsers
>>> can be built to interface with other applications, ChatterBot can be
>>> employed as a general-purpose remote console operating over instant
>>> messages.
>>>
>>> ASF projects we anticipate using in ChatterBot include:
>>>
>>> * Felix: to replace the v0.3 Shell as a module lifecycle management framework
>>> * UIMA: to aid in parsing/analyzing messages, either in individual
>>> command parsers or in the parser dispatcher
>>>
>>> Initial Goals
>>>
>>> ChatterBot v0.3 exists as a functioning prototype, but does not
>>> conform to existing standards in many areas, and needs expansion in
>>> its functionality. To this end, the project recognizes the following
>>> goals:
>>>
>>> * Conversion to Apache Felix as a core framework. This will replace
>>> the existing Shell and affect all other modules.
>>> * Proposal of a standard for chat-protocol handlers, independent of
>>> ChatterBot's specific needs.
>>> * Development of handlers for multiple chat protocols, compliant with
>>> the proposed standard, for use by ChatterBot.
>>> * Identification/development and assembly of tools useful for
>>> parsing, interpreting and processing text commands.
>>>
>>> Known Risks
>>>
>>> Orphaned Products:
>>>
>>> Currently the project has only two committers, 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
>>>
>>> Christopher Brind (brindy at brindy dot org dot uk)
>>> Donald Whytock (dwhytock at gmail dot com)
>>>
>>>
>>>
>>> On Mon, Feb 1, 2010 at 2:03 PM, Christopher Brind <br...@brindy.org.uk> wrote:
>>>> Sorry for shaking things up, but it sounds like you got the gist of things.
>>>> Using OSGi services to wire up Chatterbot makes it much more flexible in
>>>> the long run allowing developers/users to plug in alternative
>>>> implementations of things if they want to. I'm quite happy to join your
>>>> project as a committer to help guide this if you wish. :)
>>>>
>>>> Not sure about the proposal side of things, I'm sure someone will pipe up
>>>> soon enough.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
>>>>
>>>>> 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
>>>>> Chatterbot.
>>>>>
>>>>> 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?
>>>>>
>>>>> Don
>>>>>
>>>>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
>>>>> wrote:
>>>>> > 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<dw...@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
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
Ignite lists Smack as licensed under the Apache license v2
(http://www.apache.org/licenses/LICENSE-2.0), though it's not an
Apache project. I assume that license is revokable by Ignite at any
time? How does incorporating outside code work in Apache projects?
Don
On Mon, Mar 1, 2010 at 6:43 PM, Donald Whytock <dw...@gmail.com> wrote:
> Well, it seemed presumptuous to ask about mentors when I hardly had a
> community...but thank you for your consideration. Yes, mentoring
> would be appreciated.
>
> I tested my XMPP handler against two servers: Google's chat server and
> one managed by dreamhost.com. The handler is rudimentary, yes; there
> are several functions of the protocol it doesn't handle yet. A big
> one is dynamically accepting/rejecting users; at the moment I manually
> authenticate new contacts.
>
> But it does work (mixed results with Google). V0.3 will make a
> connection to its server, accept messages from authenticated contacts
> and send responses. With the right Parsers it should communicate with
> multiple users, relaying messages between them and originating
> messages based on other users' actions. I have Parsers that did this
> for v0.2 that I haven't ported over yet.
>
> The handler was a first effort for me, meant as an education in
> protocol handling. Happy to look at other things now...Thanks, I'll
> check out Smack. (http://www.igniterealtime.org/projects/smack/)
>
> Don
>
> On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> Hi,
>>
>> What about mentors? I cannot find any note you are actively searching
>> for them, but maybe I missed that.
>>
>> As I think about volunteering to mentor, my question is: Against what
>> server did you test your own XMPP implementation? Does it really work
>> as it seems to be rudimentary to me. Why didn't you use a XMPP client
>> lib like Smack?
>>
>> Thanks,
>>
>> Bernd
>>
>> On Mon, Mar 1, 2010 at 12:54, Donald Whytock <dw...@gmail.com> wrote:
>>> Hello again...
>>>
>>> Following is the revised proposal text, as posted on the wiki.
>>> Significant changes are the goals, which now focus on building the
>>> framework around Felix and devising a standard for protocol handlers
>>> to be used both inside and outside the project, and the committer
>>> list, which now includes Christopher Brind. The wiki copy is at
>>>
>>> http://wiki.apache.org/incubator/ChatterbotProposal
>>>
>>> Thanks...
>>>
>>> Don
>>>
>>> -----
>>>
>>> Proposal:
>>>
>>> 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.
>>>
>>> Version, 0.3, as of late 2009, functions with XMPP and has the
>>> capacity to function with whatever other protocols channels are coded
>>> for. V0.3, though, uses a custom shell, with rudimentary module
>>> lifecycle capability.
>>>
>>> This proposal introduces version 0.4, to be based on OSGi for module
>>> lifecycle management and event-driven module synchronization.
>>> Applications originally built for v0.2 will be ported to v0.4.
>>>
>>> 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. As command parsers
>>> can be built to interface with other applications, ChatterBot can be
>>> employed as a general-purpose remote console operating over instant
>>> messages.
>>>
>>> ASF projects we anticipate using in ChatterBot include:
>>>
>>> * Felix: to replace the v0.3 Shell as a module lifecycle management framework
>>> * UIMA: to aid in parsing/analyzing messages, either in individual
>>> command parsers or in the parser dispatcher
>>>
>>> Initial Goals
>>>
>>> ChatterBot v0.3 exists as a functioning prototype, but does not
>>> conform to existing standards in many areas, and needs expansion in
>>> its functionality. To this end, the project recognizes the following
>>> goals:
>>>
>>> * Conversion to Apache Felix as a core framework. This will replace
>>> the existing Shell and affect all other modules.
>>> * Proposal of a standard for chat-protocol handlers, independent of
>>> ChatterBot's specific needs.
>>> * Development of handlers for multiple chat protocols, compliant with
>>> the proposed standard, for use by ChatterBot.
>>> * Identification/development and assembly of tools useful for
>>> parsing, interpreting and processing text commands.
>>>
>>> Known Risks
>>>
>>> Orphaned Products:
>>>
>>> Currently the project has only two committers, 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
>>>
>>> Christopher Brind (brindy at brindy dot org dot uk)
>>> Donald Whytock (dwhytock at gmail dot com)
>>>
>>>
>>>
>>> On Mon, Feb 1, 2010 at 2:03 PM, Christopher Brind <br...@brindy.org.uk> wrote:
>>>> Sorry for shaking things up, but it sounds like you got the gist of things.
>>>> Using OSGi services to wire up Chatterbot makes it much more flexible in
>>>> the long run allowing developers/users to plug in alternative
>>>> implementations of things if they want to. I'm quite happy to join your
>>>> project as a committer to help guide this if you wish. :)
>>>>
>>>> Not sure about the proposal side of things, I'm sure someone will pipe up
>>>> soon enough.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
>>>>
>>>>> 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
>>>>> Chatterbot.
>>>>>
>>>>> 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?
>>>>>
>>>>> Don
>>>>>
>>>>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
>>>>> wrote:
>>>>> > 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<dw...@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
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
Well, it seemed presumptuous to ask about mentors when I hardly had a
community...but thank you for your consideration. Yes, mentoring
would be appreciated.
I tested my XMPP handler against two servers: Google's chat server and
one managed by dreamhost.com. The handler is rudimentary, yes; there
are several functions of the protocol it doesn't handle yet. A big
one is dynamically accepting/rejecting users; at the moment I manually
authenticate new contacts.
But it does work (mixed results with Google). V0.3 will make a
connection to its server, accept messages from authenticated contacts
and send responses. With the right Parsers it should communicate with
multiple users, relaying messages between them and originating
messages based on other users' actions. I have Parsers that did this
for v0.2 that I haven't ported over yet.
The handler was a first effort for me, meant as an education in
protocol handling. Happy to look at other things now...Thanks, I'll
check out Smack. (http://www.igniterealtime.org/projects/smack/)
Don
On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> Hi,
>
> What about mentors? I cannot find any note you are actively searching
> for them, but maybe I missed that.
>
> As I think about volunteering to mentor, my question is: Against what
> server did you test your own XMPP implementation? Does it really work
> as it seems to be rudimentary to me. Why didn't you use a XMPP client
> lib like Smack?
>
> Thanks,
>
> Bernd
>
> On Mon, Mar 1, 2010 at 12:54, Donald Whytock <dw...@gmail.com> wrote:
>> Hello again...
>>
>> Following is the revised proposal text, as posted on the wiki.
>> Significant changes are the goals, which now focus on building the
>> framework around Felix and devising a standard for protocol handlers
>> to be used both inside and outside the project, and the committer
>> list, which now includes Christopher Brind. The wiki copy is at
>>
>> http://wiki.apache.org/incubator/ChatterbotProposal
>>
>> Thanks...
>>
>> Don
>>
>> -----
>>
>> Proposal:
>>
>> 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.
>>
>> Version, 0.3, as of late 2009, functions with XMPP and has the
>> capacity to function with whatever other protocols channels are coded
>> for. V0.3, though, uses a custom shell, with rudimentary module
>> lifecycle capability.
>>
>> This proposal introduces version 0.4, to be based on OSGi for module
>> lifecycle management and event-driven module synchronization.
>> Applications originally built for v0.2 will be ported to v0.4.
>>
>> 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. As command parsers
>> can be built to interface with other applications, ChatterBot can be
>> employed as a general-purpose remote console operating over instant
>> messages.
>>
>> ASF projects we anticipate using in ChatterBot include:
>>
>> * Felix: to replace the v0.3 Shell as a module lifecycle management framework
>> * UIMA: to aid in parsing/analyzing messages, either in individual
>> command parsers or in the parser dispatcher
>>
>> Initial Goals
>>
>> ChatterBot v0.3 exists as a functioning prototype, but does not
>> conform to existing standards in many areas, and needs expansion in
>> its functionality. To this end, the project recognizes the following
>> goals:
>>
>> * Conversion to Apache Felix as a core framework. This will replace
>> the existing Shell and affect all other modules.
>> * Proposal of a standard for chat-protocol handlers, independent of
>> ChatterBot's specific needs.
>> * Development of handlers for multiple chat protocols, compliant with
>> the proposed standard, for use by ChatterBot.
>> * Identification/development and assembly of tools useful for
>> parsing, interpreting and processing text commands.
>>
>> Known Risks
>>
>> Orphaned Products:
>>
>> Currently the project has only two committers, 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
>>
>> Christopher Brind (brindy at brindy dot org dot uk)
>> Donald Whytock (dwhytock at gmail dot com)
>>
>>
>>
>> On Mon, Feb 1, 2010 at 2:03 PM, Christopher Brind <br...@brindy.org.uk> wrote:
>>> Sorry for shaking things up, but it sounds like you got the gist of things.
>>> Using OSGi services to wire up Chatterbot makes it much more flexible in
>>> the long run allowing developers/users to plug in alternative
>>> implementations of things if they want to. I'm quite happy to join your
>>> project as a committer to help guide this if you wish. :)
>>>
>>> Not sure about the proposal side of things, I'm sure someone will pipe up
>>> soon enough.
>>>
>>> Cheers,
>>> Chris
>>>
>>> On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
>>>
>>>> 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
>>>> Chatterbot.
>>>>
>>>> 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?
>>>>
>>>> Don
>>>>
>>>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
>>>> wrote:
>>>> > 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<dw...@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
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Bernd Fondermann <be...@googlemail.com>.
Hi,
What about mentors? I cannot find any note you are actively searching
for them, but maybe I missed that.
As I think about volunteering to mentor, my question is: Against what
server did you test your own XMPP implementation? Does it really work
as it seems to be rudimentary to me. Why didn't you use a XMPP client
lib like Smack?
Thanks,
Bernd
On Mon, Mar 1, 2010 at 12:54, Donald Whytock <dw...@gmail.com> wrote:
> Hello again...
>
> Following is the revised proposal text, as posted on the wiki.
> Significant changes are the goals, which now focus on building the
> framework around Felix and devising a standard for protocol handlers
> to be used both inside and outside the project, and the committer
> list, which now includes Christopher Brind. The wiki copy is at
>
> http://wiki.apache.org/incubator/ChatterbotProposal
>
> Thanks...
>
> Don
>
> -----
>
> Proposal:
>
> 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.
>
> Version, 0.3, as of late 2009, functions with XMPP and has the
> capacity to function with whatever other protocols channels are coded
> for. V0.3, though, uses a custom shell, with rudimentary module
> lifecycle capability.
>
> This proposal introduces version 0.4, to be based on OSGi for module
> lifecycle management and event-driven module synchronization.
> Applications originally built for v0.2 will be ported to v0.4.
>
> 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. As command parsers
> can be built to interface with other applications, ChatterBot can be
> employed as a general-purpose remote console operating over instant
> messages.
>
> ASF projects we anticipate using in ChatterBot include:
>
> * Felix: to replace the v0.3 Shell as a module lifecycle management framework
> * UIMA: to aid in parsing/analyzing messages, either in individual
> command parsers or in the parser dispatcher
>
> Initial Goals
>
> ChatterBot v0.3 exists as a functioning prototype, but does not
> conform to existing standards in many areas, and needs expansion in
> its functionality. To this end, the project recognizes the following
> goals:
>
> * Conversion to Apache Felix as a core framework. This will replace
> the existing Shell and affect all other modules.
> * Proposal of a standard for chat-protocol handlers, independent of
> ChatterBot's specific needs.
> * Development of handlers for multiple chat protocols, compliant with
> the proposed standard, for use by ChatterBot.
> * Identification/development and assembly of tools useful for
> parsing, interpreting and processing text commands.
>
> Known Risks
>
> Orphaned Products:
>
> Currently the project has only two committers, 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
>
> Christopher Brind (brindy at brindy dot org dot uk)
> Donald Whytock (dwhytock at gmail dot com)
>
>
>
> On Mon, Feb 1, 2010 at 2:03 PM, Christopher Brind <br...@brindy.org.uk> wrote:
>> Sorry for shaking things up, but it sounds like you got the gist of things.
>> Using OSGi services to wire up Chatterbot makes it much more flexible in
>> the long run allowing developers/users to plug in alternative
>> implementations of things if they want to. I'm quite happy to join your
>> project as a committer to help guide this if you wish. :)
>>
>> Not sure about the proposal side of things, I'm sure someone will pipe up
>> soon enough.
>>
>> Cheers,
>> Chris
>>
>> On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
>>
>>> 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
>>> Chatterbot.
>>>
>>> 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?
>>>
>>> Don
>>>
>>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>> > 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<dw...@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
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Donald Whytock <dw...@gmail.com>.
Hello again...
Following is the revised proposal text, as posted on the wiki.
Significant changes are the goals, which now focus on building the
framework around Felix and devising a standard for protocol handlers
to be used both inside and outside the project, and the committer
list, which now includes Christopher Brind. The wiki copy is at
http://wiki.apache.org/incubator/ChatterbotProposal
Thanks...
Don
-----
Proposal:
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.
Version, 0.3, as of late 2009, functions with XMPP and has the
capacity to function with whatever other protocols channels are coded
for. V0.3, though, uses a custom shell, with rudimentary module
lifecycle capability.
This proposal introduces version 0.4, to be based on OSGi for module
lifecycle management and event-driven module synchronization.
Applications originally built for v0.2 will be ported to v0.4.
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. As command parsers
can be built to interface with other applications, ChatterBot can be
employed as a general-purpose remote console operating over instant
messages.
ASF projects we anticipate using in ChatterBot include:
* Felix: to replace the v0.3 Shell as a module lifecycle management framework
* UIMA: to aid in parsing/analyzing messages, either in individual
command parsers or in the parser dispatcher
Initial Goals
ChatterBot v0.3 exists as a functioning prototype, but does not
conform to existing standards in many areas, and needs expansion in
its functionality. To this end, the project recognizes the following
goals:
* Conversion to Apache Felix as a core framework. This will replace
the existing Shell and affect all other modules.
* Proposal of a standard for chat-protocol handlers, independent of
ChatterBot's specific needs.
* Development of handlers for multiple chat protocols, compliant with
the proposed standard, for use by ChatterBot.
* Identification/development and assembly of tools useful for
parsing, interpreting and processing text commands.
Known Risks
Orphaned Products:
Currently the project has only two committers, 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
Christopher Brind (brindy at brindy dot org dot uk)
Donald Whytock (dwhytock at gmail dot com)
On Mon, Feb 1, 2010 at 2:03 PM, Christopher Brind <br...@brindy.org.uk> wrote:
> Sorry for shaking things up, but it sounds like you got the gist of things.
> Using OSGi services to wire up Chatterbot makes it much more flexible in
> the long run allowing developers/users to plug in alternative
> implementations of things if they want to. I'm quite happy to join your
> project as a committer to help guide this if you wish. :)
>
> Not sure about the proposal side of things, I'm sure someone will pipe up
> soon enough.
>
> Cheers,
> Chris
>
> On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
>
>> 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
>> Chatterbot.
>>
>> 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?
>>
>> Don
>>
>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>> > 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<dw...@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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
responders
Posted by Christopher Brind <br...@brindy.org.uk>.
Sorry for shaking things up, but it sounds like you got the gist of things.
Using OSGi services to wire up Chatterbot makes it much more flexible in
the long run allowing developers/users to plug in alternative
implementations of things if they want to. I'm quite happy to join your
project as a committer to help guide this if you wish. :)
Not sure about the proposal side of things, I'm sure someone will pipe up
soon enough.
Cheers,
Chris
On 1 February 2010 18:39, Donald Whytock <dw...@gmail.com> wrote:
> 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
> Chatterbot.
>
> 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?
>
> Don
>
> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <he...@ungoverned.org>
> wrote:
> > 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<dw...@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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>