On 17/01/07, Gordon Sim <[EMAIL PROTECTED]> 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
