If the callback method returns IMessage itself, then the user has to get
application headers out of it, then get at the actual attributes. That
looks unintuitive to me since the attributes of message are the most
important piece of the message. Bypassing IMessage completely also doesn't
make sense since it does contain useful information. Perhaps somehow making
IMessage a type of dictionary directly (rather than making
ApplicationHeaders a member of IMessage) will do the trick?
Arnaud Simon wrote:
>
> falconair wrote:
>> Here is my attempt at a simpler C# client class (I normally develop Java,
>> so
>> please excuse any missing C-sharpisms). The point here is to propose my
>> idea, rather than providing a full-fledged client (which would require
>> greater understanding of qpid than I currently posses):
>>
>> This is how a user to could subscribe to a topic:
>>
>> QpidClient qpid = new QpidClient("<host>");
>> qpid.subscribe("md.lsps").onMessage += (m) => { Console.WriteLine("===" +
>> m["symbol"] + "==="); };
>>
>>
> Looks good to me.
> Don't you want to let the user access the message body? Maybe we can
> bind the message body with the key "messageBody"?
>
> Arnaud
>
--
View this message in context:
http://n2.nabble.com/c--message-retreival-without-resorting-to-encodings-and-bytes-readers--tp2222774p2231145.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
