incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bernd.fonderm...@googlemail.com>
Subject Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Date Mon, 01 Mar 2010 16:42:43 GMT
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


Mime
View raw message