Also, consider the example of the low-level back to back client, that moves messages between brokers. It wants to do as little decoding as possible. Good reason to have lazy decoding at least at the low-level API.
Rupert On 19/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > > >> I believe what would be optimal is to use the CharSequence interface > > >> everywhere. This way String values passed to us by an application > could > > >> be directly passed all the way down the stack and encoded directly > onto > > >> the wire without an additional copy, and incoming data could be > > >> efficiently decoded into a private impl of CharSequence that could be > > >> converted to a String on demand. > > It already implements CharSequence but in the client implementation I > don't see why using that interface is particularly useful. > > Anyway there are sound performance reasons even in the client for > using AMQShortString to wrap an underlying buffer slice since it means > we don't have to decode things up front. > > Consider a client reading a message a message which has say 10 string > message properties (JMS properties). These are encoded in a field > table in AMQP. The client app may or may not use these properties - in > my experience you generally don't need all of them particularly if the > message is generic. By using the short string you can lazily decode > only when the client app asks for a property value. > > RG >
