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
