Robert Greig wrote:
On 15/01/07, Carl Trieloff <[EMAIL PROTECTED]> wrote:
Gordon makes a good point, additionally I expect from time to time we
will need to go ahead/ or do things to fix issues in the spec as we
develop. It is key that we bring these items to the list so that we can
discuss and bring them back to the AMQP Working Group for inclusion or
errata.
I will check which properties are set in the client. I didn't think we
set anything much beyond strings though.
The Java client was updated, for the purposes of JMS compatibility, to
use the set of field table types that I had previously submitted to
the AMQP list. Although there was I think general agreement on
extending the types (after lengthy debate with one person in
particular) the proposal "fizzled out".
Any string property set on the FieldTable class in the java client gets
passed as a 'wide string' which is a new, non-standard type (the
standard 'long string' value type doesn't seem to be used anymore in
field table). So the strings in the client properties can't be
understood by a broker that doesn't support that new type.
Perhaps as a quick fix to this particular problem we could make use of
the non-standard types more explicit (e.g. setWideString() on the
FieldTable class).
As I understand it, the most urgent use of these new types is in
explicitly encoding the value types for all custom JMS properties. While
I fully appreciate the desirability of this, I would also like to keep
interoperability except where the application explicitly chooses to use
non-standard extensions.
Maybe we could allow different strategies for mapping JMS message
property values to AMQP field table values. For full JMS compliance it
may be the non-standard approach is the most viable but many
applications may be able to work with other schemes e.g. transmitting
all properties as strings and converting them as and where necessary (I
realise this is not fully compliant from a JMS perspective). If the
strategies could be set via a system property, that would allow users to
trade off between AMQP compliance and JMS compliance (we could even
allow a name or value mangling hack where both could be supported albeit
in a rather nasty way).
Thoughts?
