incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: [Proposal] Blaze
Date Wed, 19 Jul 2006 17:51:32 GMT

On Jul 18, 2006, at 8:41 PM, Noel J. Bergman wrote:

> Ian Holsman wrote:
>> if blaze's goal is to create a standardized widely available and
>> interoperable messaging solution (you forgot enterprise class)
>> why is it creating a new one, and not using JMS ?
> Blaze's goal (AMQP) is to provide multple language implementations  
> of a
> language-neutral, wire-level, protocol with a ton of detailed  
> semantics for
> interoperable messaging.  JMS is a a Java API.

I am wholly behind the goal of establishing an open standard protocol  
for async messaging. Heck, I helped spec one out (which I would be  
happy to see supplanted by something better!), but I fear the way the  
protocol spec works here probably won't work well for an Apache project.

Blaze seems to be about about providing implementations of a  
proprietary protocol controlled by a group of vendors and one major  
customer. The protocol is specified behind closed doors with good  
intentioned but legally nebulous licensing. Participation in the  
protocol specification process by folks outside the initial group is  
by submitting suggestions to a private channel. The protocol is  
specifically controlled by a group of companies, with no provision  
for individual participation. On the other hand, Apache is  
specifically made up of individuals, not companies, and merit is  
based on the actions of the individual.

The protocol being implemented is pretty much controlled by a  
separate, closed body. There is presently no way for Apache  
contributors to participate in, or even observe, the protocol  
specification process. The eventual standards body to which it is to  
be submitted is unknown, and there are definitely standards bodies  
which are incompatible with Apache (any pay-to-play, or any barring  
individual participation, tend to be difficult) style development.

So basically, if the project's goal is to provide a couple reference  
implementations and various client libraries for an in-development  
closed protocol (with well intentioned licensing) which is being  
developed via a process which precludes participation by folks  
working on the Apache project unless their employer (who may not even  
be aware of their participation) signs an IP agreement? Even then,  
the path to joining the protocol specification group is by submitting  
suggestions to private discussion in which you are not included.

If the protocol came with the project, the protocol lived in a  
standards body such as the IETF, or even if the protocol was being  
developed in the open using an apache-style meritocracy, I would be  
100% for this. As it stands, I worry that it is incompatible with  


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message