Robert Greig wrote:
On 16/01/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
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.
There is a method setAsciiString, which allows you to specify short
strings. However I hadn't realised that use of setString was so
widespread at the moment.
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).
Yes, or I was going to change field table for the moment to use
non-wide strings all the time (until we get the types approved and
implemented in C++ and python etc.).
That would probably be the best short term solution and the AMQType
implementations for the various strings seem to be more or less the same
at present anyway.
Use of (some of) the non-string property types on JMS messages would
still cause problems, but that is something we can warn about and
applications can avoid it if interoperability prior to 0-10 (or
whatever) is required.
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.
The main driver was not really strings (although the length limit on
short string is an obvious issue) but for other types where we needed
to know the "real" type so that we could apply the type conversion
rules.
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).
My first reaction is: is it worth spending time doing that rather than
just getting the field table types updated in the protocol? We
previously had a name mangling rule scheme that doesn't take you any
further forward since you need to standardise those rules to achieve
interop.
Standardising on some scheme of mapping JMS property values to AMQP
field table values is required for interoperability between two
different JMS adapters, but providing the standard values are used (and
e.g. selectors aren't required) any compliant AMQP broker could be used
between them without it caring about that mapping. So while name
mangling (or some other scheme) doesn't take us further forward in a
standardised JMS mapping, it would at least avoid taking a backward step
in AMQP compliance (a standard already published). For this particular
case however, I think your suggestion above is a good pragmatic approach
for now.
I know that at present there are not many implementations of AMQP to
choose from so this is a somewhat theoretical and pedantic point but the
principle of interoperability does seem to me to be an important one.
The recent addition of a field to the basic.consume method in the 0-8
spec in the repository mean that even the c++ implementation built
against that spec would be non-compliant with the published standard of
the same version (again, of little practical significance once we move
to 0-9 where that change is standardised). The addition of the
exchange.bound method on the other hand is far less of an issue as it
wouldn't break basic messaging functionality that did not require it.
I'm not at all opposed to non-standard extensions, in fact I think they
are a great way of speeding up the improvement of the standardised
protocol through a working implementation of a valuable feature (as well
as use cases showing that value). I think it is important for us to be
explicit about the impact of any such features on interoperability until
the point that they can be standardised though, and try (as far as
possible) to provide them in such a way that we augment rather than
break the protocol and allow basic functionality to be used even where
such extensions are not supported by the peer.
I think there was general consensus that the original set of field
table types was incomplete so it shouldn't be too difficult to get it
approved. Martin typed up the proposal (which had originally be only
in an email) and put it on the wiki when he was implementing the field
table stuff:
https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal
RG
