On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > At a minimum it would be nice if FieldTable implemented the Map > interface and had a copy constructor that took a regular Map.
In fact FieldTable used to be a subclass of HashMap (or AbstractMap or something like that). I cannot remember why that was changed now - Rob can you recall? > This analysis gets a little more complicated in 0-10. In 0-10 a frame > boundary can appear anywhere, so it isn't possible to simply wrap the > bytes read in off the wire in an AMQShortString object and pass that up. In a sense we have this today (if I understand you correctly) since you may only read a partial frame off the wire. That is a lower level obviously but is AFAICS exactly the same problem. I have discussed in the past using a special implementation of ByteBuffer that can aggregate sub byte buffers to avoid copying (that is currently done in the CumulativeProtocolDecoder or something like that). > You either need to copy the bytes into a newly allocated ByteBuffer, or > have a more sophisticated AMQShortString implementation that operates on > a list of fragments. Obviously it is impossible to do the latter if > AMQShortString is used directly throughout the code. I don't follow the last sentence? AMQShortString would contain a subclass of ByteBuffer that under the hood was really multiple java.nio.ByteBuffer slices. > I actually do want to expose a non JMS interface that doesn't use > AMQShortString. There is a lot of ground between providing an AMQP > specific messaging API and providing an AMQP specific String API. And you want to postpone the creation of an AMQShortString? Your API layer could presumably hide that from the user of your API in the same way JMS does? Why does postponing the creation of the AMQShortString help? Are there cases where you might choose not to encode the string into a bytebuffer? Or are you avoiding the case of copying into a bytebuffer then copying that buffer into the buffer that contains the whole frame? RG
