qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: Use of AMQShortString in client side code
Date Wed, 19 Sep 2007 16:51:33 GMT
On 19/09/2007, Rafael Schloming <rafaels@redhat.com> wrote:

> Yes, except 0-10 adds another level of this since frames are the unit
> you read off of the wire, and those can't be directly parsed without
> aggregating them.

Presumably there is a size so you can pull in all the chunks before
starting parsing?

> So for the 0-10 transport code you either end up doing
> two full copies if you want to provide contiguous byte buffers to the
> codec, or you make the codec deal with non contiguous byte buffers. I
> chose the latter, and also stopped using the CumulativeProtocolDecoder
> as there was no need anymore.

That makes sense.

> I have something similar to this. It's not an implementation of
> ByteBuffer, it's just a Decoder object that knows how to read primitive
> AMQP types out of a list of multiple ByteBuffers. It's a bit simpler
> than a full ByteBuffer impl, but it has much the same effect.

Fair enough, I think a full ByteBuffer like the above would be useful
for MINA though if you are feeling community-spirited.

> You're right, in theory I could modify or subclass the MINA ByteBuffer
> to provide this functionality. That is something I would rather avoid
> doing though as to date I've managed to keep MINA dependencies quite
> isolated.

I think MINA should be able to move away from their ByteBuffer
wrapper, or at least make their ByteBuffer extend java.nio.ByteBuffer.
Maybe that is something we should modify and suggest to them since I
agree it is a pain to have MINA bytebuffers scattered around the

> I actually don't want to bother going through AMQShortString at all. If
> the user passes me a String the most efficient thing for me to do is
> encode that directly onto the wire.

OK, I buy that.

> The other issue is that the generated API is at this point quite usable
> on its own, however usage of AMQShortString would make it unsuitable as
> a public API.

Of course (without having seen your API admittedly) only people who
have a burning desire to couple themselves to the protocol would want
to use such an API and presumably they would be happy to couple
themselves to AMQShortString too. If they weren't they could use the
One True API viz. "Extended AMQP JMS".


> So I'm forced to make something of a choice here, either
> generate code that is unusable as a public API, or generate code that is
> unusable by the broker because it is too slow.

To me, CharSequence is fine unless someone comes up with a method in
AMQShortString that needs to be there but isn't in CharSequence.


View raw message