qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: AMQP 0-9 support
Date Wed, 17 Jan 2007 18:28:07 GMT
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.


> 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.


View raw message