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 <dwhyt...@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 <bri...@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 <dwhyt...@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<bri...@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<dwhyt...@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-unsubscr...@incubator.apache.org >>> >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> >> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> > For additional commands, e-mail: general-h...@incubator.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
