On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> 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
