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 Thu, 20 Sep 2007 07:21:37 GMT
On 20/09/2007, Rafael Schloming <rafaels@redhat.com> wrote:
> Robert Greig wrote:
> That depends on the details of how tokenizing would work. It's not 100%
> clear to me how you'd apply a generalized tokenizing scheme to AMQP as
> some shortstrs are intended for the broker to interpret, and some
> shortstrs are intended for the receiving client to interpret.

I had assumed there would be a type TokenizableShortString in the
protocol which the broker would always have to interpret and that
would exist only in places where it made sense (i.e. where you would
always be parsing it anyway). But thinking about that further now,
there are clearly some problems with that such as whether you allow
such things to be squirreled away inside field tables etc.

> Defining a scheme that is specific to exchange name and routing key is
> probably just simpler and easier. And of course making it fixed width
> permits easy access to hardware for monitoring and acceleration.

What length is being considered? I am just concerned that it may be
quite long if it's to be useful, or there needs to be a namespace
associated somewhere else e.g. with a producer (not a concept that
exists currently) or consumer. For example you might want to create a
queue called:

com.megabank.ib.fixedincome.repo.IncomingRepos

which has length 46.

> I could do this, but my code already uses String in the API and it
> already lazily encodes from String->ByteBuffer, so I think this would be
>  functionally equivalent to what I'm doing now.

So if I understand your comment correctly that sounds like a plan?

RG

Mime
View raw message