Adding translation isn't *that* hard - it'd take me a few hours I guess... The issue is more that there don't seem to be any (even de-facto) standards for content type when encoding maps in 0-9-1. A quick google shows that people talking from one RabbitMQ focussed client to another have been told to use JSON or similar to serialize their data.
I agree that not having standard content encodings for structured data was a fault in AMQP 0.x versions - and one that we fixed in AMQP 1.0 (and for the message translation in the Java Broker, amqp maps will be turned into AMQP 1.0 map data and vice versa). I'll have a think about the best way to implement something here for the Java Broker so that it can work out if a) the client is likely to be able to understand the message content encoding and then b) how to translate the message into something the receiving client can understand. -- Rob On 18 May 2016 at 13:45, Alex Szczuczko <aszcz...@redhat.com> wrote: > Rob, > > I see your reply in the list archive, but since I'm not subscribed (not > interested other than for this thread), and a direct reply wasn't copied to > me, I will have to break threading (hopefully not too much) to reply to you. > > > On 17 May 2016 at 18:59, Alex Szczuczko <aszcz...@redhat.com> wrote: > > > Hi, > > > > > > I'm trying to send a message from a Qpid 0.32 Python client (which uses > > > protocol 0-10), to Qpid Java Broker 6.0.2, and receive it with a 0-9-1 > > > protocol client (amqpy 0.12.4). The message content/body is a Python > > > dictionary, which is transparently encoded as a AMQP 0-10 map[1] by the > > > sending client. Instead of an AMQP 0-9-1 field-table[2], the receiving > > > client gets the untranslated AMQP 0-10 map, which it can only present > as a > > > raw byte string. > > > > > > Is the "translates among all versions of AMQP" feature[3] of the Java > > > Broker supposed to include conversion of message bodies? Looking at > > > MessageConverter_0_10_to_0_8.java[4] it seems to only convert > > > headers/properties, and the body is just passed through unchanged. This > > > doesn't meet my impression of what is implied by the feature > description. > > > > This is an interesting issue. The problem here is that both AMQP 0-9-1 > > and AMQP 0-10 are silent on the issue of message encoding - both simply > > define a transport for opaque binary messages, with properties (and > > particularly the content-type property) being used to indicate to the > > ultimate recipient the nature of the message being transmitted. Since > > sending structured data (e.g. maps) is such a natural thing to want to > do, > > and since each version of AMQP supports a type system which includes a > > representation of these structured types, it is natural that > > clients/applications have defined their own MIME types to represent these > > encodings, and used the native type systems of AMQP to transport the > data. > > The issue is that these MIME types are not standardised and not > necessarily > > common between clients. To take a concrete example, the Qpid Java JMS > > client for AMQP 0-9-1 does not use FIeldTable to represent JMS Map > > Messages, and would not know how to present a field table encoded message > > through its JMS API. On the other hand it is perfectly able to decode > the > > AMQP 0-10 map encoded message content because it understands that MIME > type. > > I suspected it might be something like that. The lack of standard content > types is disappointing, and takes away a lot of AMQP's value in my opinion. > > > > > I think what we need here is a way to indicate for each client which MIME > > types it "accepts" and to introduce message content translation between > > MIME types so that we can convert from types not understood by a > particular > > recipient into types that are understood. This is may even occur > between a > > sender and receiver of the same protocol (see the example above where the > > Qpid JMS client would require translation of the FieldTable map message, > or > > the JMS client may send and 0-10 encoded message over and 0-9-1 > connection). > > > > I'll raise a JIRA for this presently - as a start can you tell me the > > content type that the amqpy client is using when it is sending messages > > containing field tables? > > The example I gave was the opposite: Qpid Python (sender) to amqpy > (receiver), but I've attached Wireshark packet dumps for both directions > (which include the dissected content-types). > > It seems that amqpy as a sender doesn't do anything transparently, but > I've used its AMQPWriter to translate the Python dict into a field-table. > The content-type it gives is blank, and I can't see a conventional > equivalent to amqp/map for field tables. So, content translation may not be > possible with amqpy as a sender, unless the broker inspected the content > independently. > > Adding content translation looks very difficult, so maybe all that can be > done is to update the features list and/or documentation to disclaim that? > > Alex > > > > > Thanks, > > Rob
