Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dwhytock@gmail.com designates
 209.85.220.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=orhNvpWn7y2hk+ji1qvWzgT51MfxOXXDwpV1R9GRLABnVwr5CWF35qJRrVBaqp9PYR
         iLMTyeXeUTefGsDHNrOGpXArRiQinxUu/C93URPLYXVZCXhHdlfBM8FFCmxYMlRALTcR
         FrFrg3YbC11JFrhTV/xtZtjGZdUbtxoZnzjkw=
MIME-Version: 1.0
In-Reply-To: <15b968381003011543g33ea4ae9x740e7ce1bdbdc850@mail.gmail.com>
References: <15b968381001281932w41cc5832t24c163e380cff9a2@mail.gmail.com>
	 <36fe576b1001290044x68a8f3a8qd30cdd048947bf98@mail.gmail.com>
	 <15b968381001290738nee5c1b3wf6095c297a1df4fb@mail.gmail.com>
	 <4B630741.4020307@ungoverned.org>
	 <15b968381002011039v8e975d0xc70547155425038@mail.gmail.com>
	 <36fe576b1002011103q6255476bn7fbc323e4d5b0638@mail.gmail.com>
	 <15b968381003010354x268bbb2chc0237030b1498789@mail.gmail.com>
	 <88f6e29a1003010842s148334dck429a9e45e2d98630@mail.gmail.com>
	 <15b968381003011543g33ea4ae9x740e7ce1bdbdc850@mail.gmail.com>
Date: Mon, 1 Mar 2010 19:24:53 -0500
Message-ID: <15b968381003011624x5a5dba85i55fe2032c04ed7c4@mail.gmail.com>
Subject: Re: [PROPOSAL] Chatterbot, a lightweight framework for chat
	responders
From: Donald Whytock <dwhytock@gmail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <dwhytock@gmail.com> wrote:
> Well, it seemed presumptuous to ask about mentors when I hardly had a
> community...but thank you for your consideration. =A0Yes, mentoring
> would be appreciated.
>
> I tested my XMPP handler against two servers: Google's chat server and
> one managed by dreamhost.com. =A0The handler is rudimentary, yes; there
> are several functions of the protocol it doesn't handle yet. =A0A big
> one is dynamically accepting/rejecting users; at the moment I manually
> authenticate new contacts.
>
> But it does work (mixed results with Google). =A0V0.3 will make a
> connection to its server, accept messages from authenticated contacts
> and send responses. =A0With the right Parsers it should communicate with
> multiple users, relaying messages between them and originating
> messages based on other users' actions. =A0I 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. =A0Happy 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
> <bernd.fondermann@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,
>>
>> =A0Bernd
>>
>> On Mon, Mar 1, 2010 at 12:54, Donald Whytock <dwhytock@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. =A0The 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. =A0It is written in Java SE, and runs as a Java
>>> application. =A0Chat 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:
>>>
>>> =A0* Small: The current framework consists of eight core classes.
>>> =A0* Standalone: ChatterBot does not require external servers to operat=
e.
>>> =A0* Portable: ChatterBot should work as run from any Java-capable
>>> machine. =A0For full functionality that machine should have internet
>>> access, but localhost and console connectivity are possible. =A0It
>>> should be possible to run multiple instances of ChatterBot on the same
>>> machine or on separate machines with no loss of functionality.
>>> =A0* Extensible: An instance of ChatterBot can support multiple message
>>> parsers and protocols. =A0Adding more is done by editing a configuratio=
n
>>> file.
>>> =A0* Dynamic: Activating and de-activating modules should be possible
>>> during runtime.
>>> =A0* 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. =A0Such 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. =A0Thus applications can be accessed from web interfaces,
>>> instant-message systems, text messages, email, etc. =A0A 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. =A0It 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. =A0The 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. =A0This version was structured
>>> entirely around XMPP. =A0The 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. =A0V0.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. =A0This 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). =A0Donald Whytock has several years of experience as a
>>> software developer, working in a variety of languages, including C,
>>> Java, Perl, PHP, JavaScript and SQL. =A0He 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. =A0As 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:
>>>
>>> =A0* Felix: to replace the v0.3 Shell as a module lifecycle management =
framework
>>> =A0* 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. =A0To this end, the project recognizes the following
>>> goals:
>>>
>>> =A0* Conversion to Apache Felix as a core framework. =A0This will repla=
ce
>>> the existing Shell and affect all other modules.
>>> =A0* Proposal of a standard for chat-protocol handlers, independent of
>>> ChatterBot's specific needs.
>>> =A0* Development of handlers for multiple chat protocols, compliant wit=
h
>>> the proposed standard, for use by ChatterBot.
>>> =A0* 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. =A0As modular as the project is, however, open-source
>>> collaboration should not be a problem. =A0It 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. =A0This 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:
>>>
>>> =A0* chatterbot-private
>>> =A0* 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 <brindy@brindy.org.uk=
> wrote:
>>>> Sorry for shaking things up, but it sounds like you got the gist of th=
ings.
>>>> =A0Using OSGi services to wire up Chatterbot makes it much more flexib=
le in
>>>> the long run allowing developers/users to plug in alternative
>>>> implementations of things if they want to. =A0I'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 <dwhytock@gmail.com> wrote:
>>>>
>>>>> I had originally thought that Felix Shell would replace Chatterbot
>>>>> Listener, but I no longer think so. =A0Felix 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).) =A0On the oth=
er
>>>>> 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 o=
n:
>>>>>
>>>>> - Building Chatterbot around Felix as a modularity framework, with it=
s
>>>>> 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 se=
e
>>>>> now that that conflicts with a term of art) would work best as a
>>>>> service. =A0I'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? =A0A new proposal draft?
>>>>>
>>>>> Don
>>>>>
>>>>> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall <heavy@ungoverned.o=
rg>
>>>>> 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=3Doverview
>>>>> >>
>>>>> >> 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. =A0My intent was to allow
>>>>> >> multiple chat IDs (same protocol or different protocols) to transl=
ate
>>>>> >> into a single Chatterbot ID, so that a user could choose how he
>>>>> >> accessed the bot. =A0Which 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 S=
hell
>>>>> >> and Commands, if the Shell was fed a JMS stream consolidated from
>>>>> >> multiple message streams, and if its output was then dispersed ove=
r
>>>>> >> multple message streams. =A0Though there would also need to be a w=
ay 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:
>>>>> >
>>>>> > =A0 =A0http://felix.apache.org/site/apache-felix-shell.html
>>>>> >
>>>>> > And
>>>>> >
>>>>> > =A0 =A0http://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 an=
d 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. =A0Would this compare to Felix Event Admin?
>>>>> >>
>>>>> >> That pretty much just leaves the global namespace, which is
>>>>> >> essentially volatile JDO. =A0This 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. =A0I've implemented that as a T=
reeSet
>>>>> >> 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. =A0Especially if it'll still run off my USB
>>>>> >> drive.
>>>>> >>
>>>>> >> Don
>>>>> >>
>>>>> >> On Fri, Jan 29, 2010 at 3:44 AM, Christopher Brind<brindy@brindy.o=
rg.uk
>>>>> >
>>>>> >> =A0wrote:
>>>>> >>
>>>>> >>>
>>>>> >>> 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. =
=A0Apache
>>>>> >>> already has a modularity solution (Felix) based on an open standa=
rd
>>>>> >>> (OSGi) I
>>>>> >>> don't think the Java community as a whole needs yet another modul=
arity
>>>>> >>> solution. =3D) =A0 Felix also provides a shell which allows you t=
o manage
>>>>> >>> module
>>>>> >>> (bundle) lifecycle (install, start, stop, update, uninstall) and =
while
>>>>> I
>>>>> >>> don't know what the status is regarding the 'Standard Shell' (OSG=
i RFC
>>>>> >>> 132)
>>>>> >>> it is quite easy to add new commands to the Felix shell. =A0 Feli=
x 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 we=
ll 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 a=
s I've
>>>>> >>> implied, it would have to be compatible with OSGi which is where =
I
>>>>> spend
>>>>> >>> most of my time. =A0I'd even offer to assist that effort on this =
project.
>>>>> >>>
>>>>> >>> This is more of a question, is there any Java API standard abstra=
ction
>>>>> >>> for
>>>>> >>> chat protocols? =A0e.g. javax.chat? =A0I don't think there is but=
 there is
>>>>> of
>>>>> >>> course JMS, is ChatterBot significantly different from JMS? =A0If=
 so,
>>>>> >>> perhaps
>>>>> >>> a low priority side goal of the project should be to develop a st=
andard
>>>>> >>> Java
>>>>> >>> API standardisation for chat?
>>>>> >>>
>>>>> >>> Cheers,
>>>>> >>> Chris
>>>>> >>>
>>>>> >>>
>>>>> >>> On 29 January 2010 03:32, Donald Whytock<dwhytock@gmail.com> =A0w=
rote:
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Hello all...
>>>>> >>>>
>>>>> >>>> As discussed before, here is the current wiki text of the propos=
al for
>>>>> >>>> Chatterbot, a lightweight framework for chat responders. =A0The =
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 contain=
er for
>>>>> >>>> chat responders.
>>>>> >>>>
>>>>> >>>> Proposal
>>>>> >>>>
>>>>> >>>> ChatterBot is a framework for developing chat responders (applic=
ations
>>>>> >>>> that respond to messages received via online chat) and a contain=
er for
>>>>> >>>> deploying them. It is written in Java SE, and runs as a Java
>>>>> >>>> application. Chat responders are built by extending a single cla=
ss 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 op=
erate.
>>>>> >>>>
>>>>> >>>> - Portable: ChatterBot should work as run from any Java-capable
>>>>> >>>> machine. For full functionality that machine should have interne=
t
>>>>> >>>> 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 mes=
sage
>>>>> >>>> parsers and protocols. Adding more is done by editing a configur=
ation
>>>>> >>>> file.
>>>>> >>>>
>>>>> >>>> - Dynamic: Activating and de-activating modules should be possib=
le
>>>>> >>>> during runtime.
>>>>> >>>> Multi-user access: Multiple users, over multiple protocols, shou=
ld 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 whi=
ch the
>>>>> >>>> responder communicates. Such an interface is more secure than
>>>>> >>>> interfaces such as Telnet or web services since it does not requ=
ire
>>>>> >>>> open ports in the firewall; the container connects out through t=
he
>>>>> >>>> firewall to the chat server, rather than allowing users to conne=
ct in.
>>>>> >>>>
>>>>> >>>> A lightweight chat responder can be installed on any system to a=
llow
>>>>> >>>> command-line access to users over whatever protocol a user may h=
ave
>>>>> >>>> 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 de=
sired.
>>>>> >>>>
>>>>> >>>> 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 bridg=
e
>>>>> >>>> between applications, where one or more uses a chat protocol suc=
h 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 mak=
e as
>>>>> >>>> general-purpose a server as possible, so that multiple games cou=
ld 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 implemen=
t a
>>>>> >>>> room system that allowed for room-specific applications -- parse=
rs
>>>>> >>>> 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 all=
ow
>>>>> >>>> modules to communicate with relatively limited coupling.
>>>>> >>>>
>>>>> >>>> The current version, 0.3, as of late 2009, functions with XMPP a=
nd 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 woul=
d be
>>>>> >>>> built as an application using 0.3.
>>>>> >>>>
>>>>> >>>> Current Status
>>>>> >>>>
>>>>> >>>> Meritocracy
>>>>> >>>>
>>>>> >>>> Peer review and alternate ideas are welcomed in this project wit=
h open
>>>>> >>>> arms. This project was intended specifically as an alternative t=
o
>>>>> >>>> traditional server-based or enterprise architecture; however, it=
 is
>>>>> >>>> recognized that tried-and-tested principles established in enter=
prise
>>>>> >>>> architecture may be applicable here.
>>>>> >>>>
>>>>> >>>> Core Developers
>>>>> >>>>
>>>>> >>>> As of late 2009, there is one developer, Donald Whytock (dwhytoc=
k at
>>>>> >>>> gmail dot com). Donald Whytock has several years of experience a=
s a
>>>>> >>>> software developer, working in a variety of languages, including=
 C,
>>>>> >>>> Java, Perl, PHP, JavaScript and SQL. He develops both profession=
ally
>>>>> >>>> and casually; ChatterBot has been an independent, voluntary effo=
rt.
>>>>> >>>>
>>>>> >>>> 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 buil=
t to
>>>>> >>>> utilize other technologies. Embedded Derby is used in one applic=
ation;
>>>>> >>>> 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 clas=
ses
>>>>> >>>> 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 incomin=
g and
>>>>> >>>> outgoing messages.
>>>>> >>>> Potential refinements: an interface for relaying XML/HTML data w=
ithin
>>>>> >>>> messages
>>>>> >>>>
>>>>> >>>> Listener: The driving module that routes messages to Parsers.
>>>>> >>>> Maintains a list of Parsers, submitting an incoming message to e=
ach
>>>>> >>>> Parser in turn until a Parser indicates successful handling.
>>>>> >>>>
>>>>> >>>> Parser: The abstract class for message-parsing modules.
>>>>> >>>> Potential refinements: built-in parsing/tokenization, persistenc=
e
>>>>> >>>>
>>>>> >>>> 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 connect=
ions
>>>>> >>>> with other processes.
>>>>> >>>>
>>>>> >>>> ConsoleChannel: Extends Channel; supplies a simple Swing console=
 for
>>>>> >>>> entering messages and receiving responses.
>>>>> >>>>
>>>>> >>>> INIParser: Extends Parser, allows examination and manipulation o=
f the
>>>>> >>>> global namespace.
>>>>> >>>>
>>>>> >>>> New modules should be developed to add optional functionality. I=
n
>>>>> >>>> particular, new Channels should be developed for AIM, YM, MSN, e=
tc.
>>>>> >>>> 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 serve=
r
>>>>> >>>> non-dependence.
>>>>> >>>>
>>>>> >>>> RoomParser: Extends Parser; implements chatrooms, relaying messa=
ges
>>>>> >>>> among users in a room and allowing room-specific applications.
>>>>> >>>>
>>>>> >>>> Known Risks
>>>>> >>>>
>>>>> >>>> Orphaned Products
>>>>> >>>>
>>>>> >>>> Currently the project has only one committer, though Donald Whyt=
ock
>>>>> >>>> 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 prod=
ucts,
>>>>> >>>> this is the first time opening up a project for open-source
>>>>> >>>> collaboration. As modular as the project is, however, open-sourc=
e
>>>>> >>>> collaboration should not be a problem. It is greatly desired tha=
t 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 i=
ts
>>>>> >>>> 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.o=
rg
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >> ------------------------------------------------------------------=
---
>>>>> >> 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