On 09/16/2009 07:34 PM, Bill Whiting wrote:
I'm replacing other messaging with qpid. I have code for marshalling
and demarshalling data that uses byte-order to know how to handle
integers. I can add a custom property to the message that provides byte
order, but it would be preferrable to have the byte-order of the sender
implemented in the API.
I'm not as convinced. It doesn't seem like the sort of information that
most applications will want automatically included in their headers
which means you would need some mechanism to enable it, and in that case
are you really gaining much?
In the general case the content type would need to be set by the
application anyway, to let the receivers know the format. Appending
information on the byte-order to that seems like a reasonable approach
to me since it is relevant only to the decoding.
//Bill
On 09/16/2009 11:37 AM, John Dennis wrote:
On 09/16/2009 11:25 AM, Bill Whiting wrote:
That is exactly the case, I'm thinking of parsing fixed record format
data. If the remote system is big-endian (or just different from me)
then I want to determine how to handle the data.
Why not just write the content in network byte order?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
