I guess that one thing you might want to bear in mind is
interoperability, for example say your producer clients are C++ based
and consumers are say Java based.
Am I not right in thinking that setting content-type in a C++ client
causes a particular mapping when deserialised in Java so text/plain
winds up as a TextMessage, amqp/map as a MapMessage?, amqp/list as ....
well best not start me off on that again :-)
I *guess* that it's possibly/probably the case that setting to something
that isn't one of those might cause a default ByesMessage mapping (which
would make sense to me) so say "image/jpeg" would probably end up as
BytesMessage content with the content-type available in JMSType (I think
- it used to be necessary to down cast do a Qpid specific class to get
the content-type but I think recent versions of Qpid have this available
in JMSType, but I'm not sure the version this behaviour became available)
TBH I generally send data as opaque BytesMessage unless I'm doing QMF2
stuff and I mostly use Java so I haven't really tried out what exciting
effects occur with C++ producers and Java consumers so I may be
completely off the mark, but TBH I'd quite like to know myself for
future reference.
Frase
On 23/08/13 13:44, Gordon Sim wrote:
On 08/23/2013 12:33 PM, kevency_poche wrote:
i will work on those and get back to you. the spout and drain
executables
are useful to send some text. If i want to send something like
images,audio,
etc. Is it possible using this c++ broker ?
Excuse me, if this is a silly question .
Not a silly question at all. The fact that the content is set as a
std::string doesn't imply that it is textual in nature. It is
essentially just a sequence of bytes. So yes it is certainly possible.
For AMQP 0-10 you can set the content-type to 'text/plain' to indicate
that it is textual data, and of course you could set that to some
other mime-type to indicate some other binary form (e.g. image/jpeg or
whatever).
In future there will be an extension to the API (already on trunk, but
won't be released until 0.26), that lets you set the content as an
object (a qpid::types::Variant). That allows the std::string to be
associated with an encoding (utf8, ascii or binary), as well as
allowing it to be a map, list, uuid or one of various numeric types.
In hindsight the API would likely have been clearer had
std::vector<uint8_t> been used in place of std::string. That may be an
addition that gets made at some point also.
---------------------------------------------------------------------
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]
