On 09/17/2009 03:47 AM, Gordon Sim wrote:
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.
Why not enable this for all applications? If an application doesn't
need or want the information it won't hurt to have it along for the ride.
//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]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
