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 <[email protected]> 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
