> -----Original Message----- > Sent: Monday, April 27, 2009 11:20 AM > > Alan Conway wrote: > > Jonathan Robie wrote: > >> On the whole, I really like this. Comparing the example > programs to > >> the existing examples, I think it does simplify quite a bit. > >> > >> A few thoughts: > >> > >> 1. Streaming data into or out of messages > >> > >> I really want to be able to stream into or out of messages > directly. > >> > >> Instead of: > >> > >> message_data << "Message " << i; > >> message.setData(message_data.str()); > >> > >> I would like to be able to do something like: > >> > >> message.getData() << "Message " << i; > >> > > > > The problem here is that there are many different ways that users > > might want to encode their messages. ostream-style streaming as > > human-readable strings is great for demos but quite unlikely for a
> > real application. So I would be reluctant to build it into > the Message > > class. I think it's best to keep Message's role entirely > separate from > > the business of encoding, so users can format their data using any > > method they like and then attach it to the message. > > I don't think of streaming as just a way to format things as > characters, I think of it primarily as a model for creating things > incrementally. Good point. However, if message.getData() returns a string reference, it will be formatted as characters. > I come from the "minimize the movement of data" school, and I > also like my APIs to be clear about when data is managed. I agree. > Right now, if I copy a string to a message using setData() it is > referenced counted and not copied, but if I then append to it > it is copied. Note that this behavior is for g++'s string and is not universal, so I wouldn't count on that when designing an API. > 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 ;-) -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
