So I think what we said - and I can't find it written down anywhere in the draft, though we reference the JSON spec in the pre-amble, is that any value in the headers or body should be able to be sent in the native AMQP type (and we might need some words there about converting between various numeric types), or as a JSON serialized string. We didn't (to my recollection) talk about whether there should be a way for the requester to be able to influence the form of the reply.
Currently the implementation of AMQP Management in the Qpid Broker for Java follows the above conventions (any inbound value can be in the native type, or as a JSON string which can convert to the desired type, however there is no mechanism for controlling the nature of responses). Perhaps this is something we should talk about soon ;-) ? -- Rob On 18 January 2017 at 14:29, Ted Ross <[email protected]> wrote: > > > On 01/18/2017 07:45 AM, Gordon Sim wrote: > >> On 18/01/17 10:45, Rob Godfrey wrote: >> >>> In terms of sending maps/lists I think we said (at OASIS), though it is >>> possibly not yet in the draft spec, that Json formatted equivalents >>> should >>> be able to be used for all values... however I have no idea if the >>> Dispatch >>> Router supports that. >>> >> >> I think that would be very sensible. >> > > Dispatch Router does not support Json formatted bodies at present, but > this is a feature that I would be in favor of putting on the roadmap. > > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
