qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 23:22:01 GMT
On 17/01/07, Gordon Sim <gsim@redhat.com> wrote:
> Achieving JMS compliance has necessitated some non-standard protocol
> extensions/alterations. To use all JMS features, only a broker that
> supports these extensions/alterations can be used (currently only the
> java broker[*]). Further, the java client can not at present be used in
> *any* capacity with a broker that does not support these extensions.

I think it is worth separating the particular issue in this case (i.e.
the changes made to field table and so on) so that we as a group can
try to agree on some general principles and rules for qpid's
relationship with AMQP.

My own view is that we must not lose sight of the fact that qpid is
tracking a specification that is still evolving rapidly - currently
version 0.8 with 0-9 in progress. Also the qpid codebase itself is
being changed a lot, and we have only had one milestone release. Given
that rate of change, is it sensible for qpid *trunk* to track an AMQP
specification? Or even offer any guarantees of interoperability?

How do the following rules sound to people:

1) Qpid releases will support a particular published version of the
AMQP specification.

2) Qpid trunk should be considered a work in progress that may not
support a published AMQP specification. People using trunk are using
bleeding edge software.

3) Up to AMQP 1.0 (whenever that is published) Qpid will not offer
backwards compatibility between versions. After AMQP 1.0 is released,
qpid releases will be backwards compatible for major versions of AMQP.

RG

Mime
View raw message