I like the discussion on message content. Given Alan's recent suggestions, I can easily envisage how an implementation could optimize the Receiver case and lazily extract the content from the underlying protocol frames into the form required by the application, and avoid an intermediate memory copy.
IstreamView(m).read(myMemPtr, m.getContentSize()); i.e., I don't just get the content, I get it where it needed to go. As a bonus, it can plug right into a decoder, again streaming straight from the protocol frames. The reverse direction is not symmetrical. If you insert content into the message (by assignment or via an ostream), how can the implementation know at this point what the frame content size will be? Message m; // set headers // insert content... but where is this message going? mySender.send(m); // frames get created here I can only see two potential solutions to the problem (being mindful of the frame set lifecycle issues that were mentioned). 1. provide a way to associate a message (or subclass, or the MessageContent) with a connection/session on creation, or prior to inserting content. Something like: Message m = mySession.CreateMessage(); 2. provide an optional pull mechanism, such as assigning an istream to the content, where the implementation can create the frames directly at the time of the Sender.send(). The former is more sensible for use with an encoder... a powerful motivation for this option. The latter compartmentalizes the performance optimization as an optional-use API and does the right thing if you send the same message over two different connections. Plus you could do cutesy things with custom istreams, such as reading from disk or a database directly into the frame set. Cliff --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
