On 20 December 2016 at 18:34, Gordon Sim <g...@redhat.com> wrote: > On 20/12/16 18:20, Keith W wrote: >> >> On 20 December 2016 at 10:14, Gordon Sim <g...@redhat.com> wrote: >>> >>> On 19/12/16 15:57, Keith W wrote: >>>> >>>> >>>> By debugging the Java Broker's translation module, I can see that the >>>> AMQP 1.0 publishing end is sending the map encoded within a >>>> DataSection. This surprises me - I was expecting the application-data >>>> to be an amqp-value containing the map. The Java Broker doesn't know >>>> how to translate this for the 0-10 and hence the test fails. >>>> >>>> Why does Qpid Python / swigged client encode the map this way? >>> >>> >>> >>> The swig layer has some special logic for managing message content that >>> predates 1.0 and works the same way for both 1.0 and 0-10. The >>> content-type >>> is used to indicate the type in both cases. >>> >>> 1.0 required some changes to the messaging API (set-/get- >>> ContentObject()) >>> to allow value sections to be used. I suspect the swig binding was just >>> never changed to use those changes. >>> >> >> Thanks Gordon for the swift reply. That all makes sense and I was >> able to find the code concerned. It matches your suspicions. >> Do you know if the bindings are due to have their AMQP 1.0 support >> refreshed? > > > I don't know of any such plan. The swigged client is really only used for > tests at present. >
I believed that Python Messaging derived its AMQP 1.0 support by way of the swigged client. Are we saying this is deprecated? If so, what is the preferred Qpid Python client for AMQP 1.0? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
