In general, I am in agreement with this approach, and I certainly think that a common API shared by all the client languages, with respect to their quirks and conventions, is a good thing.
One thing to bear in mind: On 17/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
obviously). This will have the advantage to only support a single JMS implementation.
Our existing customers are using the JMS API. However, some of them are also using unofficial extensions to that API, for example some extra methods to allow the sending of immediate and mandatory messages, some listener interfaces to receive failover notifications on the connection, and so on. If possible, I think we need to retain these JMS API extensions, to make the migration path onto the 0.10 Java client as smooth as possible. I feel that the correct way to move forward would be to take note of what these extra methods are, and if they are to become redundant, mark them as deprecated for a some time before replacing them with alternatives. It might be worth introducing an interface or two into the 0.8 client to capture these API extensions, then carry those interfaces forward into 0.10. Rupert
