qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Use of AMQShortString in client side code
Date Wed, 19 Sep 2007 17:12:27 GMT
On 19/09/2007, Robert Greig <robert.j.greig@gmail.com> wrote:
>
> 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
> place.
>
> > 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.
>
> RG
>



What encoding has been defined for shortstrs in 0-10?  In particular do we
know precisely how to encode a sequence of unicode characters (which is what
a CharSequence is)?

BTW I agree that we don't want to be going via a ByteBuffer if not
necessary... One of the reasons of using AMQShortString was so that I could
swap out the implementation at will.  Using a CharSequence interface (or
similar) will lead us to code which does instanceof checks when we know that
particular implementations can be used more efficiently.


-- Rob

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message