On Wed, 2007-01-17 at 12:25 +0000, Gordon Sim wrote: > Achieving JMS compliance has necessitated some non-standard protocol > extensions/alterations. To use all JMS features, only a broker that > supports these extensions/alterations can be used (currently only the > java broker[*]). Further, the java client can not at present be used in > *any* capacity with a broker that does not support these extensions. >
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. My feeling is that 1) Any new feature in Qpid should be implemented using standard extension points in AMQP unless it is utterly unfeasible to do so, and if that's the case there should be discussion to establish that it really is utterly infeasible - and that discussion should spill onto the AMQ protocol lists to highlight the shortcoming of the protocol. 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. 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. Cheers, Alan.
