On 14/09/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
I am planning a refactoring of the java client to create an AMQP client API and then build the JMS layer on top of it. So people who are interested can directly access AMQP specific features.
The approach we had taken before was to have an "extended JMS" API that exposed additional methods and potentially interfaces, e.g. org.apache.qpid.jms.Session extends javax.jms.Session. I would be interested to understand what kind of features you would like to expose? Do you think the existing approach is not adequate for your needs, i.e. do you want to create a completely un-JMS-like API? My initial thought is that I don't like the general idea of have two APIs - two is one too many unless there is a good functional or historical reason for it. It asks users to make a choice they may not feel comfortable making (are you saying to users that to get the "full power" of AMQP you need to use our proprietary API?). JMS is by its nature a compromise of an API, hence why we wanted to extend it like most JMS implementations, and some AMQP concepts are relatively tricky to map (the Destination concept in JMS being the most obvious example). Maybe we can do better here, although I think that Martin's great work on the URIs helps a lot in making it easier for the users. In other languages, where there is no standard messaging API we have freedom to create whatever API feels best for that language but for Java I believe JMS will for the time being be the primary API. Maybe if AMQP takes off with other messaging vendors we would be able to get some of our extensions added to a future version of JMS.
Since Robert seem to be back I am going to talk with him and settle on the direction.
I'm still just checking mail sporadically but will be back full time from Monday. RG
