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
