As an aside, I would argue that for a low level API, AMQShortString would be the correct type for the argument to a declareQueue method, as the valid set of names for a queue is not (java.lang.)String but only (a subset of) those that can be represented by AMQShortString. (Obviously higher level APIs (such as JMS) will offer String as the type, but we need a well defined encoding to convert these into AMQShortString representation).
-- Rob On 22/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
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 >
