Robert Godfrey wrote:
Currently we don't actually support file and stream, just basic, so we
won't really be in a different position with respect to spec compliance,
we're just converting our basic support to message support.
Which is fine, but if we are working off the public spec then Basic is
still
current whereas Message is marked as Work In Progress. We have to be very
clear that we are moving to virtual non-compliance with the published spec.
We are doing this for good reasons (i.e. we are confident that the spec
will
move into conformance with QPID), but we will likely cease to be compatible
with any non-QPID AMQP implementations.
Agreed
Personally I don't have an issue with getting ahead of the spec, I think
we just need to be more careful about how we do it so that a) we don't
break interoperability between the different qpid implementations at the
very least, and b) so that we don't needlessly break compatibility with
the spec when it would be just as easy to extend the spec, e.g. by
choosing type codes for the new field table types that don't conflict
with the spec defined type codes.
Agreed - we should agree QPID-wide ennhancements where we believe these are
necessary, rather than having each client/broker add its own
"enhancements". Obviously there has never been an intention to
deliberately
cause incompatibility with the spec (choosing conflicting field table
types), however a wider review of such enhancements before they are made
would hopefully reveal such bugs before they are implemented.
Also, where we do consciously choose to go off spec it might not be a
bad idea to have some sort of negotiation at connection initiation so
that we can distinguish between plain vanilla clients and clients that
understand our extensions.
My view is that hopefully the broker should do anything that will prevent
clients talking to each other at the same "level" of the protocol. That is
that two QPID clients should be able to communicate using our enhanced
spec,
but that the broker would equally well cope with two clients talking
vanilla
AMQP. The agreement is really between the two clients as to what protocol
they speak which needs to be made at system deployment time rather than
runtime I think.
This depends on the area of the enhancement/incompatibility. What you're
saying is mostly the case for message/header encoding issues. For those
features it's primarily the two clients that need to understand each
other and the broker can pretty much stay out of the way as long as it
can understand enough of the message to route it correctly.
For other kinds of spec changes it may be reasonable to allow clients
with different capabilities to interoperate, e.g. in principle there is
no reason that a vanilla 0-8 client couldn't publish a message to a
consumer that supports filters.
I'm not sure that protocol negotiation would necessarily help. For
instance, in the case we are talking about (FieldTables). the publishing
client would negotiate to use QPID "enhanced". The potential recipient of
the message negotiates to use vanilla AMQP. What should the broker do?
Not
send the message to the recipient because of the protocol version
differences? Attempt to re-encode the message according to the negotiated
protocol?
I'd say just generate a friendly error message. If we don't at a minimum
have a way to detect this situation then clients are going to connect
and die with a very cryptic error message somewhere in the depths of the
deserialization code.
Hopefully this is only a relatively short term problem while the spec is
eveolving. Once the spec is stable I would hope that QPID would no longer
have any "enhancements" to worry about.
I agree it's worse now, but I suspect that our development will continue
to lead the spec even past the 1.0 version, in which case we will need
some kind of negotiation because we can't have all our clients and
brokers advertising AMQP 1.0 during negotiation and then using project
specific extensions.
--Rafael
