On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> However for JMS users, they can cast down to the native Qpid Interface and
> use AMQP features.
> (This is something I initially disagreed, but I understand that this may
> provide a more gradual migration path)
I should point out that one of the nice things about Java 5 is that
due to covariant return types you don't need to cast since you can do
(e.g.):
public interface Connection extends javax.jms.Connection
{
qpid.jms.Session createSession(boolean transacted, int ackmode);
}
assuming that qpid.jms.Session extends javax.jms.Session of course.
This is great since it means people *do not have to cast* in general,
and just have to change their imports.
> As a side effect of my arguments during the debate I may have given the
> impression that the Qpid API is competing against the JMS API.
> Instead they are two different approaches we present to the end user and
> they will make a judgement based on their situation.
> We should provide good documentation highlighting the pros/cons for each
> approach.
I do not believe this is a judgement our users want to make, or need to make.
> The Qpid API (or client) should be the recomended approach if the users
> primary goal is to work at the AMQP level.
I think we need to be very clear about the scope and use cases for such an API.
RG
