qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: AMQP 0-9 support
Date Wed, 17 Jan 2007 14:45:58 GMT
>
>
> 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.

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.

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?

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.

- Rob

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message