Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread Paul Fremantle
+1 [binding]

Paul

On Sat, Jan 30, 2010 at 7:40 AM, Matt Hogstrom  wrote:
>  [X] +1 to recommend Cassandra's graduation
> (binding)
>
> On Jan 28, 2010, at 2:59 PM, Eric Evans wrote:
>
>>
>> Greetings,
>>
>> We took the feedback from the earlier discussion[1] here and added our
>> active mentors to the proposed PMC, (for a total of 7 people), then ran
>> that through a new community vote[2].
>>
>> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
>> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
>>
>> There didn't seem to be any other feedback, so I'd like to start an
>> official vote to recommend graduation of Apache Cassandra to a top-level
>> project.
>>
>> Please cast your vote:
>> [ ]  0 don't care
>> [ ] -1 no, don't recommend yet, (because...)
>>
>> The vote will be open for 72 hours.
>>
>> Thanks,
>>
>> --
>> Eric Evans
>> eev...@rackspace.com
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>
> Matt Hogstrom
> m...@hogstrom.org
>
> A Day Without Nuclear Fusion Is a Day Without Sunshine
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>



-- 
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
p...@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread Matt Hogstrom
 [X] +1 to recommend Cassandra's graduation
(binding)

On Jan 28, 2010, at 2:59 PM, Eric Evans wrote:

> 
> Greetings,
> 
> We took the feedback from the earlier discussion[1] here and added our
> active mentors to the proposed PMC, (for a total of 7 people), then ran
> that through a new community vote[2].
> 
> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
> 
> There didn't seem to be any other feedback, so I'd like to start an
> official vote to recommend graduation of Apache Cassandra to a top-level
> project.
> 
> Please cast your vote:
> [ ]  0 don't care
> [ ] -1 no, don't recommend yet, (because...)
> 
> The vote will be open for 72 hours.
> 
> Thanks,
> 
> -- 
> Eric Evans
> eev...@rackspace.com
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Matt Hogstrom
m...@hogstrom.org

A Day Without Nuclear Fusion Is a Day Without Sunshine


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Discussion: graduating Subversion

2010-01-29 Thread Matt Hogstrom
Bring it on 

On Jan 25, 2010, at 3:49 PM, Greg Stein wrote:

> Hi all,
> 
> Before calling for a vote to graduate Subversion, I figured it prudent
> to have a discussion first. I believe Subversion is quite ready (and
> has been, but the holidays and whatnot kept me from sending this
> earlier).
> 
> Any thoughts on why Subversion should NOT graduate now?
> 
> Thanks,
> -g
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

Matt Hogstrom
m...@hogstrom.org

A Day Without Nuclear Fusion Is a Day Without Sunshine


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



[jira] Assigned: (INCUBATOR-106) MetaCarta Lucene Connector Framework code grant

2010-01-29 Thread Grant Ingersoll (JIRA)

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll reassigned INCUBATOR-106:
-

Assignee: Grant Ingersoll

> MetaCarta Lucene Connector Framework code grant
> ---
>
> Key: INCUBATOR-106
> URL: https://issues.apache.org/jira/browse/INCUBATOR-106
> Project: Incubator
>  Issue Type: New Feature
>Reporter: Karl Wright
>Assignee: Grant Ingersoll
> Attachments: apache-lcf-software-grant.tar.gz
>
>
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ dpkg --list | grep 
> coreutils
> ii  coreutils  6.10-6 
>   The GNU core utilities
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ md5sum 
> apache-lcf-software-grant.tar.gz
> 1e429efbc2359a18912948411e09a76f  apache-lcf-software-grant.tar.gz
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



[jira] Updated: (INCUBATOR-106) MetaCarta Lucene Connector Framework code grant

2010-01-29 Thread Karl Wright (JIRA)

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright updated INCUBATOR-106:
--

Attachment: apache-lcf-software-grant.tar.gz

This constitutes the initial legal software grant of Lucene Connector Framework 
code from MetaCarta, Inc.
 

> MetaCarta Lucene Connector Framework code grant
> ---
>
> Key: INCUBATOR-106
> URL: https://issues.apache.org/jira/browse/INCUBATOR-106
> Project: Incubator
>  Issue Type: New Feature
>Reporter: Karl Wright
> Attachments: apache-lcf-software-grant.tar.gz
>
>
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ dpkg --list | grep 
> coreutils
> ii  coreutils  6.10-6 
>   The GNU core utilities
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ md5sum 
> apache-lcf-software-grant.tar.gz
> 1e429efbc2359a18912948411e09a76f  apache-lcf-software-grant.tar.gz
> kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



[jira] Created: (INCUBATOR-106) MetaCarta Lucene Connector Framework code grant

2010-01-29 Thread Karl Wright (JIRA)
MetaCarta Lucene Connector Framework code grant
---

 Key: INCUBATOR-106
 URL: https://issues.apache.org/jira/browse/INCUBATOR-106
 Project: Incubator
  Issue Type: New Feature
Reporter: Karl Wright


kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ dpkg --list | grep 
coreutils
ii  coreutils  6.10-6   
The GNU core utilities
kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$ md5sum 
apache-lcf-software-grant.tar.gz
1e429efbc2359a18912948411e09a76f  apache-lcf-software-grant.tar.gz
kwri...@kuskokwim:~/export-area/apache-lcf-software-grant$


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread Matthieu Riou
+1
(high five!)

Matthieu

On Thu, Jan 28, 2010 at 11:59 AM, Eric Evans  wrote:

>
> Greetings,
>
> We took the feedback from the earlier discussion[1] here and added our
> active mentors to the proposed PMC, (for a total of 7 people), then ran
> that through a new community vote[2].
>
> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
>
> There didn't seem to be any other feedback, so I'd like to start an
> official vote to recommend graduation of Apache Cassandra to a top-level
> project.
>
> Please cast your vote:
> [ ] +1 to recommend Cassandra's graduation
> [ ]  0 don't care
> [ ] -1 no, don't recommend yet, (because...)
>
> The vote will be open for 72 hours.
>
> Thanks,
>
> --
> Eric Evans
> eev...@rackspace.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>


[Vote] Release Kato M1-incubating

2010-01-29 Thread Stuart Monteith
The Kato community has voted to release Kato M1-incubating. We now 
request the

Incubator PMC for a vote.

The proposed release artifacts are located at:
http://people.apache.org/~monteith/kato/apache-kato-M1-incubating-RC3/

There are packages for the Java binaries with documentation, source and 
native libaries for Linux and Windows x86.
Each package is available in tar.gz and zip form, expect for the native 
packages.

asc, md5 and sha1 (SHA512) files are generated for each.

rat*.txt files have been generated for each of the packages contents. 
The mapping is:

apache-kat-M1-incubating-bin.(tar.gz|zip) - rat-bin.txt
apache-kat-M1-incubating-src.(tar.gz|zip) - rat-src.txt
apache-kat-M1-incubating-native-bin-linux-i386.tar.gz - 
rat-bin-linux.txt
apache-kat-M1-incubating-native-bin-windows-i386.zip - 
rat-bin-windows.txt


Please review the artifacts and cast your vote by Thursday 4th February.


Thanks in advance,
Stuart Monteith

--
Stuart Monteith
http://blog.stoo.me.uk/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

2010-01-29 Thread Richard S. Hall

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  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  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 hav

Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

2010-01-29 Thread Donald Whytock
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.

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  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  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 multip

Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread Bertrand Delacretaz
> [X ] +1 to recommend Cassandra's graduation

Congrats!
-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread Matthias Wessendorf
[X] +1 to recommend Cassandra's graduation
(binding)

On Thu, Jan 28, 2010 at 8:59 PM, Eric Evans  wrote:
>
> Greetings,
>
> We took the feedback from the earlier discussion[1] here and added our
> active mentors to the proposed PMC, (for a total of 7 people), then ran
> that through a new community vote[2].
>
> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
>
> There didn't seem to be any other feedback, so I'd like to start an
> official vote to recommend graduation of Apache Cassandra to a top-level
> project.
>
> Please cast your vote:
> [ ] +1 to recommend Cassandra's graduation
> [ ]  0 don't care
> [ ] -1 no, don't recommend yet, (because...)
>
> The vote will be open for 72 hours.
>
> Thanks,
>
> --
> Eric Evans
> eev...@rackspace.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

2010-01-29 Thread Christopher Brind
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  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 com

Re: [VOTE] Graduate Apache Cassandra to an Apache TLP

2010-01-29 Thread ant elder
+1

   ...ant

On Thu, Jan 28, 2010 at 7:59 PM, Eric Evans  wrote:
>
> Greetings,
>
> We took the feedback from the earlier discussion[1] here and added our
> active mentors to the proposed PMC, (for a total of 7 people), then ran
> that through a new community vote[2].
>
> [1] http://thread.gmane.org/gmane.comp.apache.incubator.general/24427
> [2] http://thread.gmane.org/gmane.comp.db.cassandra.user/2157
>
> There didn't seem to be any other feedback, so I'd like to start an
> official vote to recommend graduation of Apache Cassandra to a top-level
> project.
>
> Please cast your vote:
> [ ] +1 to recommend Cassandra's graduation
> [ ]  0 don't care
> [ ] -1 no, don't recommend yet, (because...)
>
> The vote will be open for 72 hours.
>
> Thanks,
>
> --
> Eric Evans
> eev...@rackspace.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



[Announce] Apache UIMA 2.3.0 released

2010-01-29 Thread Marshall Schor
The Apache UIMA development community is pleased to announce the release
of version 2.3.0 of UIMA (Unstructured Information Management
Architecture).  Apache UIMA is a framework supporting combining and
reusing components that annotate unstructured information content such
as text, audio, and video.

This release consists of 4 packages:

 - UIMA Java SDK - the base framework, with development tools and examples
 - UIMA-AS (Asynchronous Scalout capability)
 - UIMACPP (c++ support framework, for components written in c++ and
other languages)
 - UIMA Addons - a growing set of annotators and other tools.

This release is generally backwards compatable with previous releases,
except that Java 5 is now the minimum Java level required.

The add-ons package contains many new components and annotators, including:

  - Bean Scripting Framework supporting annotators written in popular
scripting languages
  - Lucas - an interface to using UIMA with Apache Lucene
  - TikaAnnotator - an annotator using the Apache Tika project text
extractors

The UIMA-AS (Asynchronous Scaleout) framework is extensively enhanced
with much more support for error/failure recovery, driven by feedback
from actual use in several large scale deployments (1000's of nodes).
The base framework now supports Java 5 generics, and is enhanced to make
it even more light-weight and efficient; for example, it now supports a
new network serialization format for communicating with remote
annotators using a "delta-CAS" - limiting the response sent to just
those items which have changed.

Full information and summaries of the changes are contained in the
release notes, which you can find on our downloads page - scroll down to
the 2.3.0 release section, and click on the package of interest in the
release notes column.

Apache UIMA welcomes your help.  Any contribution (code, testing,
documentation, bug reporting/fixing) is always appreciated.  For more
information on how to get involved, please visit the website at:

  http://incubator.apache.org/uima

Thank you for your interest in Apache UIMA.

-The Apache UIMA development community



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org