Rupert Smith wrote:
So the generic 'handle' method has its uses, but it may be something that is
to remain internal to the comm layer, rather than exposed as part of the
API.
Yes, the generic handler chain (i.e. handle(Event<Session,Method>
event), or handle(Event<Channel,Method> event) depending on what layer
you're in) is needed for when you want to process all the different
kinds of Methods in the same way, for example you could have some sort
of logging or security interceptor that operates at that level. So it
could be useful at some point to expose it as part of the API in that
capacity, however at this point it could be viewed as purely internal.
As soon as you want to perform some action that is specific to that
particular kind of Method, e.g. when you get to the end of the handler
chain, you really want to be using a delegate (i.e. queueDeclare(Session
ssn, QueueDeclare qdecl)).
And it is trivial to adapt between the two:
class DelegateAdapter<C> implements Handler<Event<C,Delegator<C>>>
{
private Delegate<C> delegate;
public DelegateAdatper(Delegate<C> delegate)
{
this.delegate = delegate;
}
public void handle(Event<Session,Delegator<C>> event)
{
event.target.delegate(event.context, event.target);
}
}
--Rafael
On 02/08/07, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Rupert Smith wrote:
I think that both Alan and I are saying that use of (QueueDeclare qd) as
an
argument to the queueDeclare method has advantages over using (String
queueName, boolean durable, ...)
I agree. The only exception I have made to this in the design of the
code in org/apache/qpidity is to provide the Invoker abstract class as a
convenient alternative to manually constructing the QueueDeclare and
then passing it in. As I see it there are no disadvantages to providing
this alternative because you can always use the other form if you wish.
The difference between the two eaxample you give, is whether the method
handler is a generic 'handle' method or a specifically names
'queueDeclare'
method. But that wasn't really the point being made by either of us.
I must have read that into Alan's post.
For the record, I think for an API, the specific method name is
superior. I
could be won around to the generic 'handle' method point of view, if you
would care to try and pursuade me.
I agree that the specific method name is superior, particularly for
handling incoming method calls as it permits the delegate itself to be
stateful in its handling of incoming methods. This is actually quite
important as it provides a powerful tool for isolating the core of the
broker from details of the protocol interaction.
--Rafael
Rupert
On 02/08/07, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Alan Conway wrote:
On Thu, 2007-08-02 at 10:07 +0100, Rupert Smith wrote:
Hi,
I have thought of another reason why I think the AMQP methods as
interfaces
approach may be useful. As already mentioned the delegate/invoker
interfaces
are symmetric opposites viewed from the client and broker sides. This
means
that the routing/delivery layer of the broker will implemented the
invoker
interface for incoming method calls, and the client will implement it
for
outgoing method calls.
Quick example:
interface MessageInvoker
{
public void messageTransfer(Session context, MessageTransfer mt);
... more
}
class ClientMessageImpl implements MessageInvoker { ... }
class BrokerDeliveryEngine implements MessageInvoker { ... }
That's pretty much how the C++ broker does it except each AMQP class
is
an interface i.e. you have Message { transfer(...); get(...); etc. }
I would quite like to break them into individual per-method interfaces
because it gives more flexibility to distribute the work among classes
(e.g. the clustering stuff wants to treat "wiring" differently from
"non-wiring" which means handling a subset of the Queue and Exchange
classes.) Not sure if this will happen in C++ in the immediate future
though, as most of the clustering work so far is dealing with frames
below the semantic layer.
I'm not sure Rupert and Alan are talking about the same thing. As I
understand it Alan is talking about having distinct classes handling
incoming methods, and Rupert is talking about using interfaces rather
than method arguments as part of the client API.
From what I understand, Rupert is suggesting that this is a superior
client API:
QueueDeclare qdecl = factory.newQueueDeclare("queue-name", ...);
ssn.queueDeclare(qdecl);
And I believe Alan is suggesting that this is a superior interface for
handling incoming methods:
QueueDeclareHandler {
public void handle(Session ssn, QueueDeclare qdecl);
}
I'm pretty sure one of the three of us is confused. Are the above
descriptions accurate or am I the one that is confused?
--Rafael
