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:users-subscribe@qpid.apache.org
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org