On 09/17/2009 07:48 AM, Bill Whiting wrote:
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.
I'm not convinced either. You've essentially got a private protocol
inside an AMQP content block. Most network protocols handle byte order
on their own. They either write in network byte order or they include a
byte order marker in the protocol. You can either add an application
specific header as metadata to the AMQP message to convey the sender's
byte order, or follow the conventional network protocol practices noted
above (which would be of benefit if you ever use a transport other than
AMQP). None of this requires a change to AMQP, which seems like a
minority case, especially since it appears you're not following best
practice in your private embedded protocol to begin with.
--
John Dennis <[email protected]>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
