Also, perf test suite should really have been coded to the JMS api only. Something I intend to change eventually...
On 22/06/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
This method is only used from the performance test suite as a convenience for creating a queue. We have never made attempts to expose the underlying AMQP as an API. If we were to do such a thing then a lang.String would of course be the natural choice. Currently all Strings in the client API that are sent across the network are AMQShortStrings. This was a change made to aid performance. Continued conversion between String and the Short String format for the wire was quite an overhead in the Java client. I would suggest that we put the put an item on the agenda for the Java F2F to discuss an AMQP API but as there are a lot of things that are changing with the protocol perhaps the best thing to do is if you find the createQueue method useful but would rather have a String method then create one that does the AMQShortString wrapping for you (Most of the other JMS API/Public calls do something similar). When the 0_10 AMQP is released then I'm sure we can address any API mapping we wish to do. On 21/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote: > Here's the signature for createQueue(): > > createQueue(final AMQShortString name, final boolean autoDelete, final > boolean durable, > final boolean exclusive) throws AMQException > > Why an AMQShortString for the name - wouldn't a Java string be simpler? > > Should we provide different signatures for this method, providing > defaults for some of the arguments? > > Jonathan > -- Martin Ritchie
