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. 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?).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
