qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: C# API boilerplate
Date Wed, 03 Dec 2008 22:01:33 GMT
2008/12/2 Shahbaz Chaudhary <schaudhary@marcopolonetwork.com>:

> 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.


View raw message