qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: c++ messaging api: a map message example
Date Thu, 06 Aug 2009 19:47:44 GMT
On 08/06/2009 04:31 AM, Gordon Sim wrote:
> Alan Conway wrote:
>> On 08/05/2009 02:45 AM, Gordon Sim wrote:
>>>> This looks messy:
>>>> listener.subscribed(session.subscribe("message_queue", listener));
>>>>
>>>> Informing the listener can be done as part of the implementation of
>>>> session.subscribe(), it doesn't
>>>> need to be left to the user.
>>>
>>> I'll have a think about this.
>>
>> My main objection to the line above is the fact that listener is
>> mentioned twice. What does it mean if you use two different listeners?
>> I think its an error, in which case the API should be modified to make
>> that error impossibl, e.g. by doing the whole thing atomically in
>> sesision.susbcribe. This also avoids the error where the user forgets
>> to call listener.subscribed(). I'm assuming here that part of the
>> semantics of MessageListener is that it will get a call to
>> subscribed() each time it is subscribed.
>
> The Listener::subscribed() call in this example is really part of the
> example code, not the API, as with the existing direct_listener example
> which it emulates.

Good point, maybe just clarify that by breaking the line:

Subscription subscription  = sesssion.subscribe(...);
listener.subscribed(subscription);

to make it (sort of) clearer that listener.subscribed is not really part of 
subscribing, it's something extra the demo does.

The Session::subscribe() call that takes a subclass
> of MessageListener is part of the API itself; the listener there is
> simply a callback through which to notify the application of received
> messages.
>
> Whether or not the MessageListener should contain a callback used to
> notify it of its use for a particular subscription is something I'd need
> to think about a bit more. I want to revisit the details of the use of
> listeners anyway (e.g. should the listener actually be set on a receiver
> instance, as in the python equivalent?).
>

Now that I'm thinking straight(er) I don't think we should extend the 
MessageListener API unless there's a very compelling reason. Its nice and simple 
as it is, long may it remain so.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message