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
