Robert Greig wrote:
On 18/01/07, Gordon Sim <[EMAIL PROTECTED]> 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.
But the current trunk is still tracking 0-8 I think (i.e. thats the
version of the spec in use and echoed on connection handshaking).
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).
If the c++ code is based on 0-10 (i.e. that is the spec it builds off
and announces on connection startup) and doesn't support all the types
then yes, that would in my view imply a 'known bug' in the c++ code,
preventing full use of the protocol.
