incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <dwhyt...@gmail.com>
Subject Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Date Tue, 02 Mar 2010 00:24:53 GMT
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.  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
> <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,
>>
>>  Bernd
>>
>> 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.  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 <brindy@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 <dwhytock@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 <heavy@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<dwhytock@gmail.com>
 wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Hello all...
>>>>> >>>>
>>>>> >>>> As discussed before, here is the current wiki text of
the proposal for
>>>>> >>>> Chatterbot, a lightweight framework for chat responders.
 The proposal
>>>>> >>>> is at
>>>>> >>>>
>>>>> >>>> http://wiki.apache.org/incubator/ChatterbotProposal
>>>>> >>>>
>>>>> >>>> Interested in comments, feedback and participation.
>>>>> >>>>
>>>>> >>>> Thanks...
>>>>> >>>>
>>>>> >>>> Don
>>>>> >>>>
>>>>> >>>> - wiki text -
>>>>> >>>>
>>>>> >>>> Abstract
>>>>> >>>>
>>>>> >>>> ChatterBot is a lightweight, multiprotocol framework
and container for
>>>>> >>>> chat responders.
>>>>> >>>>
>>>>> >>>> Proposal
>>>>> >>>>
>>>>> >>>> ChatterBot is a framework for developing chat responders
(applications
>>>>> >>>> that respond to messages received via online chat) and
a container for
>>>>> >>>> deploying them. It is written in Java SE, and runs as
a Java
>>>>> >>>> application. Chat responders are built by extending
a single class and
>>>>> >>>> modifying a configuration file to reference the new
class.
>>>>> >>>> ChatterBot's focus is on the following characteristics:
>>>>> >>>>
>>>>> >>>> - Small: The current framework consists of eight core
classes.
>>>>> >>>>
>>>>> >>>> - Standalone: ChatterBot does not require external servers
to operate.
>>>>> >>>>
>>>>> >>>> - Portable: ChatterBot should work as run from any Java-capable
>>>>> >>>> machine. For full functionality that machine should
have internet
>>>>> >>>> access, but localhost and console connectivity are possible.
It should
>>>>> >>>> be possible to run multiple instances of ChatterBot
on the same
>>>>> >>>> machine or on separate machines with no loss of functionality.
>>>>> >>>>
>>>>> >>>> - Extensible: An instance of ChatterBot can support
multiple message
>>>>> >>>> parsers and protocols. Adding more is done by editing
a configuration
>>>>> >>>> file.
>>>>> >>>>
>>>>> >>>> - Dynamic: Activating and de-activating modules should
be possible
>>>>> >>>> during runtime.
>>>>> >>>> Multi-user access: Multiple users, over multiple protocols,
should be
>>>>> >>>> able to access deployed applications.
>>>>> >>>>
>>>>> >>>> Rationale
>>>>> >>>>
>>>>> >>>> A chat responder can serve as a user interface to applications,
either
>>>>> >>>> those built into the responder or external applications
with which the
>>>>> >>>> responder communicates. Such an interface is more secure
than
>>>>> >>>> interfaces such as Telnet or web services since it does
not require
>>>>> >>>> open ports in the firewall; the container connects out
through the
>>>>> >>>> firewall to the chat server, rather than allowing users
to connect in.
>>>>> >>>>
>>>>> >>>> A lightweight chat responder can be installed on any
system to allow
>>>>> >>>> command-line access to users over whatever protocol
a user may have
>>>>> >>>> access to. Thus applications can be accessed from web
interfaces,
>>>>> >>>> instant-message systems, text messages, email, etc.
A scalable
>>>>> >>>> container can allow as many or as few access protocols
as are desired.
>>>>> >>>>
>>>>> >>>> ChatterBot, therefore, has value for those circumstances
where a user
>>>>> >>>> interface is needed but a server-based or enterprise
solution is
>>>>> >>>> either not possible or not desired. It also can serve
as a bridge
>>>>> >>>> between applications, where one or more uses a chat
protocol such as
>>>>> >>>> XMPP to communicate.
>>>>> >>>>
>>>>> >>>> Background
>>>>> >>>>
>>>>> >>>> ChatterBot began in 2005 as a thin-server approach to
online
>>>>> >>>> multi-user board games, implemented as applets sending
gamestate
>>>>> >>>> changes to one another via message relaying. The idea
was to make as
>>>>> >>>> general-purpose a server as possible, so that multiple
games could be
>>>>> >>>> built that employed the same message-relaying system.
>>>>> >>>>
>>>>> >>>> Version 0.2 of the server was then refined in 2008 to
allow for more
>>>>> >>>> varied and functional message-handlers, and was used
to implement a
>>>>> >>>> room system that allowed for room-specific applications
-- parsers
>>>>> >>>> that checked the user's room before handling a command
and sent
>>>>> >>>> responses to other room occupants. This version was
structured
>>>>> >>>> entirely around XMPP. The global namespace was introduced
to allow
>>>>> >>>> modules to communicate with relatively limited coupling.
>>>>> >>>>
>>>>> >>>> The current version, 0.3, as of late 2009, functions
with XMPP and has
>>>>> >>>> the capacity to function with whatever other protocols
channels are
>>>>> >>>> coded for. Applications built using 0.2 are being ported
to 0.3. At
>>>>> >>>> this point the original thin-server backend intended
in 0.1 would be
>>>>> >>>> built as an application using 0.3.
>>>>> >>>>
>>>>> >>>> Current Status
>>>>> >>>>
>>>>> >>>> Meritocracy
>>>>> >>>>
>>>>> >>>> Peer review and alternate ideas are welcomed in this
project with open
>>>>> >>>> arms. This project was intended specifically as an alternative
to
>>>>> >>>> traditional server-based or enterprise architecture;
however, it is
>>>>> >>>> recognized that tried-and-tested principles established
in enterprise
>>>>> >>>> architecture may be applicable here.
>>>>> >>>>
>>>>> >>>> Core Developers
>>>>> >>>>
>>>>> >>>> As of late 2009, there is one developer, Donald Whytock
(dwhytock at
>>>>> >>>> gmail dot com). Donald Whytock has several years of
experience as a
>>>>> >>>> software developer, working in a variety of languages,
including C,
>>>>> >>>> Java, Perl, PHP, JavaScript and SQL. He develops both
professionally
>>>>> >>>> and casually; ChatterBot has been an independent, voluntary
effort.
>>>>> >>>>
>>>>> >>>> Alignment
>>>>> >>>>
>>>>> >>>> ChatterBot's primary potential alignment with ASF is
that of a
>>>>> >>>> framework for internet-accessible applications. At its
core, it is
>>>>> >>>> largely free of outside dependencies, though modules
can be built to
>>>>> >>>> utilize other technologies. Embedded Derby is used in
one application;
>>>>> >>>> use of Derby and/or ORM should be explored as a base
capability.
>>>>> >>>>
>>>>> >>>> Initial Goals
>>>>> >>>>
>>>>> >>>> ChatterBot currently exists as a functioning prototype;
protocol
>>>>> >>>> modules built for it provide access to chat responders
via
>>>>> >>>> XMPP/Jabber, localhost connections and a chat-simulating
console.
>>>>> >>>> Further development is to consist of refinement of the
core classes
>>>>> >>>> and expansion of the secondary modules.
>>>>> >>>>
>>>>> >>>> Core Classes
>>>>> >>>>
>>>>> >>>> Shell: The main-method class, used to launch the application.
>>>>> >>>> Potential refinements: re-entrance, clean shutdown,
restart
>>>>> >>>>
>>>>> >>>> Listable: The foundation class for the global namespace.
>>>>> >>>> Potential refinements: configuration file format, persistence
>>>>> >>>>
>>>>> >>>> Module: The interface for all modules loaded by Shell.
>>>>> >>>> Potential refinements: restart, shutdown
>>>>> >>>>
>>>>> >>>> Channel: The interface for protocol handlers that accept
incoming and
>>>>> >>>> outgoing messages.
>>>>> >>>> Potential refinements: an interface for relaying XML/HTML
data within
>>>>> >>>> messages
>>>>> >>>>
>>>>> >>>> Listener: The driving module that routes messages to
Parsers.
>>>>> >>>> Maintains a list of Parsers, submitting an incoming
message to each
>>>>> >>>> Parser in turn until a Parser indicates successful handling.
>>>>> >>>>
>>>>> >>>> Parser: The abstract class for message-parsing modules.
>>>>> >>>> Potential refinements: built-in parsing/tokenization,
persistence
>>>>> >>>>
>>>>> >>>> Sender: The module that routes outbound messages from
Parsers to
>>>>> >>>> Channels.
>>>>> >>>> Potential refinements: time-delayed messages, in-system
messages
>>>>> >>>>
>>>>> >>>> Secondary Modules
>>>>> >>>>
>>>>> >>>> XMPPChannel: Extends Channel; protocol handler for XMPP.
>>>>> >>>>
>>>>> >>>> LocalhostChannel: Extends Channel; handler for localhost
connections
>>>>> >>>> with other processes.
>>>>> >>>>
>>>>> >>>> ConsoleChannel: Extends Channel; supplies a simple Swing
console for
>>>>> >>>> entering messages and receiving responses.
>>>>> >>>>
>>>>> >>>> INIParser: Extends Parser, allows examination and manipulation
of the
>>>>> >>>> global namespace.
>>>>> >>>>
>>>>> >>>> New modules should be developed to add optional functionality.
In
>>>>> >>>> particular, new Channels should be developed for AIM,
YM, MSN, etc.
>>>>> >>>> Other potential modules include:
>>>>> >>>>
>>>>> >>>> SystemParser: Extends Parser, allows dynamic activation
and
>>>>> >>>> de-activation of modules.
>>>>> >>>>
>>>>> >>>> FileXferParser: Extends Parser; implements file transfer
between
>>>>> >>>> client and ChatterBot's host. Will require refinement
of Channel and
>>>>> >>>> protocol-specific extensions of Channel.
>>>>> >>>>
>>>>> >>>> DB: A database interface. One application built using
ChatterBot
>>>>> >>>> currently uses embedded Derby as its interface, preserving
server
>>>>> >>>> non-dependence.
>>>>> >>>>
>>>>> >>>> RoomParser: Extends Parser; implements chatrooms, relaying
messages
>>>>> >>>> among users in a room and allowing room-specific applications.
>>>>> >>>>
>>>>> >>>> Known Risks
>>>>> >>>>
>>>>> >>>> Orphaned Products
>>>>> >>>>
>>>>> >>>> Currently the project has only one committer, though
Donald Whytock
>>>>> >>>> has been working on the code for a few years and is
committed to
>>>>> >>>> seeing a functional product available.
>>>>> >>>>
>>>>> >>>> Inexperience with Open Source
>>>>> >>>>
>>>>> >>>> While the developer has experience working with open-source
products,
>>>>> >>>> this is the first time opening up a project for open-source
>>>>> >>>> collaboration. As modular as the project is, however,
open-source
>>>>> >>>> collaboration should not be a problem. It is greatly
desired that this
>>>>> >>>> project not be developed in a vacuum.
>>>>> >>>>
>>>>> >>>> Fascination with the Apache Brand
>>>>> >>>>
>>>>> >>>> Association with the Apache brand is not sought for
personal
>>>>> >>>> publicity; rather, it is sought for the associated community
and
>>>>> >>>> access to collaboration and peer review. This project
will see its
>>>>> >>>> full potential through public use and refinement, and
a product more
>>>>> >>>> refined for everyone's use is a more refined product
for the
>>>>> >>>> developer's use as well.
>>>>> >>>>
>>>>> >>>> Initial Source
>>>>> >>>>
>>>>> >>>> Original code developed by Donald Whytock.
>>>>> >>>>
>>>>> >>>> Required Resources
>>>>> >>>>
>>>>> >>>> Mailing Lists
>>>>> >>>>
>>>>> >>>> chatterbot-private
>>>>> >>>> chatterbot-dev
>>>>> >>>>
>>>>> >>>> Subversion Directory
>>>>> >>>>
>>>>> >>>> https://svn.apache.org/repos/asf/incubator/chatterbot
>>>>> >>>>
>>>>> >>>> Issue Tracking
>>>>> >>>>
>>>>> >>>> JIRA ChatterBot
>>>>> >>>>
>>>>> >>>> Initial Committers
>>>>> >>>>
>>>>> >>>> Donald Whytock (dwhytock at gmail dot com)
>>>>> >>>>
>>>>> >>>> ---------------------------------------------------------------------
>>>>> >>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> >>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> >> For additional commands, e-mail: general-help@incubator.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> > For additional commands, e-mail: general-help@incubator.apache.org
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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


Mime
View raw message