Cliff Jansen (Interop Systems Inc) wrote:
Hi Gordon,
Hi Cliff,
Thanks for the feedback, much appreciated!
Jonathan previously requested support for the stream operator and I've
had a tentative stab at exploring what that might look like as well.
In addition, I would like to see the some stream-ish functions that
are friendly to char* blobs that are not null terminated. Something
along the lines of:
MessageContent& MessageContent::write (const char* s, int n);
MessageContent& MessageContent::read (const char* s, int n); // + rewind()
or seek
As well as something like
int MessageContent::size(); // (or getSize(), getLength()...)
Message::Message(const char* s, int n);
Note that std::string is not copy-on-write in all C++ implementations.
On Windows, forcing an application to use strings for its raw data (from
a char* perspective) results in needless copies of the content:
Good point, I'll try and incorporate this into the next patch.
string tmpdata(myBlobPtr, myBlobSize); // memory copy #1
Message m(tmpdata); // m.impl->bytes gets copy #2 when constructed
// tmpdata never used again, freed when out of scope
The programmer can take evasive action:
Message m; // m.impl->bytes starts out as a sacrificial empty string
m.getBytes().assign(myBlobPtr, myBlobSize); // just one copy
but
Message m(myBlobPtr, myBlobSize);
might create the FrameSet directly, and cut out another middleman.
Since MessageContent already has abstract content (string, MAP, and
LIST), extentending the set to include char* could allow performance
optimizations:
Agreed.
For incoming messages, the actual content could be copied from the
FrameSet directly to an application buffer. (This can be a win even
on Linux when messages are larger than the connection's
maxFrameSize.) The string form can be lazilly created when needed.
For outgoing messages, the content may be placed directly in special
OS memory in preparation for network transfer.
Cliff
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Friday, July 31, 2009 10:11 AM
To: Qpid Dev; [email protected]
Subject: c++ messaging api: a map message example
Attached is a patch for a higher level, protocol independent messaging api from
c++ as last discussed some months ago. I have not had much time to spend on
this since then and so there is not a huge amount of change (mainly moving to a
better namespace and adjusting for the revised include directory layout).
There is however now an example of a sending a map message using the amqp0-10
encoding (list messages are also supported) and the message headers are now
correctly sent. Jonathan previously requested support for the stream operator
and I've had a tentative stab at exploring what that might look like as well.
As always keen to get any feedback. I'm hoping to have more time to spend on
this for the next few weeks. I'm aiming to align the c++ api with the similar
work on python (at least conceptually) and to flesh out the functionality
(determining how best to expose asynchronous completion of sends and
acknowledgements will be a likely next step).
--Gordon.
---------------------------------------------------------------------
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]
