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, ...)
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.
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.
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
>
