2008/12/2 Shahbaz Chaudhary <[EMAIL PROTECTED]>:
> Instead the example contains binary readers, bytes, encodings, etc.:
>
> BinaryReader reader = new BinaryReader(m.Body, Encoding.UTF8);
> byte[] body = new byte[m.Body.Length - m.Body.Position];
> reader.Read(body, 0, body.Length);
> ASCIIEncoding enc = new ASCIIEncoding();
I agree, I had not looked at this before but it does seem particularly
cumbersome to use.
> -----
> The code to create connection and session also looks unnecessarily
> noisy. I have to provide the queue name to the ClientSession object
> three times (twice in one method call):
>
> ssn.queueDeclare("queue1", null, null);
> ssn.exchangeBind("queue1", "amq.direct", "queue1", null);
> sn.messageSubscribe("queue1", "myDest", MessageAcceptMode.EXPLICIT,
> MessageAcquireMode.PRE_ACQUIRED, null,0, null);
Agree again, this could be improved.
> The call-back method in IMessageListener is called messageTransfer(),
> isn't it better to simply call it onMessage()?
I suspect this is the protocol leaking into the API?
> I think it will be a good idea to expose incoming message as
> Events...since that's what incoming messages are and the semantics of
> qpid subscribed messages and the Events feature match perfectly.
It does break down a bit when you're using a synchronous GET mode
(rather than a message listener).
> I realize some of the complexity exists because AMQP provides many
> features...perhaps qpid can provide a stupidly simple, default, way of
> getting at the data within a few lines?
It is certainly the job of the API to hide any complexity in the protocol.
RG
