Question and suggestion about this general topic:
Why weren't the new types simply packed inside a standard longstr?
I see the value of adding new framing types like wide strings that would be of general use to any AMQP implementation, however I don't see much value in producing a non-interoperable AMQP implementation.
Obviously one can pack any type inside a longstr, including a FieldTable... but just because one can do something... ;-) Seriously, although I wasn't party to the original proposal on additional types, it seems to me that it is a better solution to define new types than to hack these distinct types into longstr. There does not appear to me to be a huge development cost in adding these to the protocol (mostly these can be treated as pass-thru by the broker), and if we are defining a standard way of implementing JMS compliance then we need a way to differentiate between these types, and the alternative would be to define standard encodings inside a longstr, which seems needlessly inefficient. I would think that one of our goals would be to make the protocol as efficient as possible - every byte we can save, we should. I agree that a client should be capable of working in strict AMQP mode where these extensions are not used. However this would be at the cost (currently) of JMS compliance [there are other non-standard extensions to the protocol other than just the FieldTable types - if it were just the FieldTable types I would agree that it would be an unnecessary deviation from the spec. However there are bigger issues.]. Until we get changes to the protocol agreed, we can be AMQP compliant, or JMS compliant, but not both simultaneously (on a given connection). 2) Any feature that does make non-standard extensions to the protocol
should ensure that it *never* sends such extensions to a peer unless it understands such extensions. There is a standard field table passed during connection setup that would allow implementations to identify themselves for such purposes.
How can we determine that when the destination of a given message is not known when it is sent? Are we proposing that the broker is responsible for re-encoding the message? As we can see in the discussion over 0-9, the protocol is in a high degree of flux currently. I think that anybody who uses QPID at the moment has to be aware that neither the protocol nor the product have reached the level of stability and maturity where one can expect seemless interoperability (as reflected by their version numbers). Therefore anyone currently deploying QPID should be free to make the decision as to whether (for instance) JMS compliance, or interoperability with non-QPID clients is their requirement. We also have to be very clear what (possibly partial) version on AMQP any release is going to support. Until we approach 1-0 I do not believe it is wrong to implement something we believe will become part of the protocol (and I believe this is the path we should take when we implement the 0-9 WIP) as long as it does not fundamentally break the ability of AMQP compliant clients to communicate with the broker . To this point I think the Java client errs in not providing an AMQP mode where the non-standard extensions are not used.
3) Any new feature of qpid that is successfully implemented using existing protocol features may still prompt a protocol change and a simpler implementation when the new protocol is published. E.g. I would prefer to have seen the current issue implemented first using longstr, with a propposal to the AMQP working group to add wide-string to the basic framing types.
I believe the new types have been put as a proposal, however we need to push to get it adopted. Again, I agree that we should be attempting to stay true to the protocol. I guess my personal rules would be these: 1. We should never make any change to a QPID broker which will stop compliant AMQP clients communicating through the broker. 2. Every QPID client should always be interoperable with every other QPID client and the QPID broker for a defined "release". 3. It must be possible to configure the clients so that can communicate through any compliant AMQP broker to any compliant AMQP client. currently I think we may be breaking all three rules :-) We are certainly breaking 2 & 3. As we get closer to a 1-0 release of the protocol I would expect that our rule will be there are no deviations from the protocol. Fundamentally every deviation we make from the published protocol is *very bad*, and we should have been documenting these more clearly. - Rob
