Jonathan Robie wrote:
Steve Huston wrote:
I think we need a clean way to handle both binary and character data
in a streaming model. That's also very natural when
copying from files to messages.
True... The difficulty is that when you allow binary insertions
without the string intermediary, you need to provide ways to manage
packing, alignment, and byte ordering too. You end up either
reinventing something like CDR or forcing all to network byte order.
One advantage to using only strings in the message API is that it
throws the binary issues back up to the applications. The disadvantage
is that it throws the binary issues back up to the applications ;-)
framing::Buffer already has support for reading and writing many, but
not all, AMQP types portably, and I think this *is* functionality we
need to offer our users. We probably do need this for our AMQP types.
I agree that support for something like a JMS 'map message' would be a
valuable addition (possibly also something that represents a simple
sequence of typed values, i.e. like the map message but with no keys).
That is really a bundled special purpose message encoding; the user
would still obviously be free to use their own encodings as needed.
I think the 'streaming' support is a slightly different question (at
least as I understand it) and could mean one of at least two distinct
things. The first is just the convenience of using stream operators to
append to a message, the second is support for sending a large message
without having to have all its content in memory at once.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
