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 Thu, 18 Jan 2007 12:29:33 GMT
On 18/01/07, Gordon Sim <gsim@redhat.com> wrote:

> As the trunk is a moving target I don't think we can 'guarantee'
> anything (not even that it builds at any point in time!). I do think we
> should aim as far as possible to be compliant in at least a basic sense
> with the specification version in use.

Yes, I think the problems have been caused by a lack of clarity of
what we are tracking/heading towards. We are notionally heading
towards 0-9 but 0-9 does not include everything we need to be JMS
compatible, and JMS compatibility was a goal for qpid's next release.

I think that we are in a position where our next release of qpid (i.e.
M-release) can only sensibly be with 0-10.

> I would view anything that breaks compatibility (as opposed to anything
> that extends functionality in a non-standard way) as a known bug. It is
> to be expected that there may be known bugs on the trunk at any time,
> but the aim should always be to have these clearly highlighted and a
> plan in place to fix them as soon as practicable.

Unless that is an incompatibility introduced by a breaking change in
the spec we are tracking towards?

e.g. let us assume for the purposes of this discussion that field
table type enhancements is in AMQP 0-10. In that case I would not view
it as a bug that trunk java does not interop with trunk C++ at a given
point in time (although there is obviously a task there for C++ to
implement that change).

> Agreed. (It may be useful nearer the 1.0 release to try an validate any
> mechanisms we might have created for multi-version support by
> implementing two similar versions, but that would be more for our
> benefit than for our users).

Yes, a clear analysis of our multi-version strategy is almost
certainly required...


View raw message