Alan Conway wrote:
On 09/10/2009 10:22 AM, Rafael Schloming wrote:
Gordon Sim wrote:
On 09/09/2009 10:21 PM, Alan Conway wrote:
I just went over the messaging API on trunk, I scribbled some comments
on it diff attached.
Thanks, Alan, all good points!
First, the easiest point to address, Session::getLastConfirmedSent()
and Session::getLastConfirmedAcknowledged() should no longer be in
there (part of an aborted earlier approach) and I'll remove them.
* Session::reject(Message&) -> Message::reject()
I wasn't keen on this, but I can't really justify my dislike so I'll
go ahead and make that change.
I'm not a fan of this change either. As with acknowledge, reject is
really an operation on the state that the session holds about a given
message, not an operation on the message itself, so I find it a bit
incongruous to have reject on the Message.
Acknowledge acks all messages received by the session to date so its
clearly a session operation.
Reject is an operation on a specific message. It is implemented as an
update to the session state, but from the users perspective you reject a
message. Moreover its only legal to reject a message using the session
that it arrived on.
Given a choice between:
message.getSession().reject(message)
message.reject()
the latter seems simpler, more intuitive and less error prone. Why
complicate the API because of the way the implementation works?
The python API doesn't have a message.getSession() or equivalent. I've
intentionally kept messages as simple value objects so that it's easy to
create them, store them, etc, without having a session around. This of
course forces you to have access to the session when you want to reject
a message, but given that it's a bit more like session.reject(message)
rather than message.getSession().reject(message).
The reason I'm reluctant to create a magic session pointer on the
message is that the client is supposed to be able to arbitrarily process
the message, including things like serializing it to disk, converting it
to an email, waiting for a reply, etc. So by the time the client app
gets around to actually rejecting (or acking the message), I want to
allow for the possibility that it might be a copy (either direct or
indirect), and given that I don't know how that copy is made, I can't
guarantee that the magic session pointer is preserved.
Really I think the most basic form of the API is actually
session.acknowledge/reject(message-id), where there is a defined way of
extracting the message-id from a message, and so long as the message-id
can be extracted, IMHO it shouldn't matter whether the message object is
the same instance or not.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
