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