Jonathan, Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI? I have mentioned this before on the list so will be brief (well that was the aim). I really don't see any advantage to adding new a API (of any sort) on the java side. Allowing 100% compliant JMS code to just work with JNDI configuration changes for Qpid is the best thing we can do for our users. If they have spent the time to write to the JMS API and stay away from vendor locks then we should reward them by just working. Asking them to rewrite some of their code when moving to a product that is based on AMQP, which is attempting to fight against the vendor lock ins in the messaging world, sends the wrong message. If we start having vendor specific APIs in the Java space we totally devalue the AMQP offering IMHO. Sure it is nice to give people options but Java users should be encoraged to stick to the JMS API, that is until AMQP define a API which can then be adopted across all AMQP clients. I think the work that is being done to standardise the APIs of the other language clients is to be commended and will surely be of a great benefit to clients writing in those languages. However, I have yet to hear a compelling reason to have non JMS API code on the java side, even if it is just for configuration. That said, as long as you can do everthing via JNDI that you can do via the new API then user migration from other JMS products will not require code changes which in the end is how we are going to win migrating Java users. If they have to rewrite parts of their app then what happened is the open and compatble standard messaging story we are trying to sell? Regards Martin 2009/9/11 Jonathan Robie <jonathan.ro...@redhat.com>: > Rafael Schloming wrote: >> >> Rafael Schloming wrote: >>> >>> The upshot is you can sort of look at these as providing a JMS-like API >>> plus some critically missing bits minus some extra cruft. >> >> One thing I should say before someone accuses me of bashing our JMS client >> too much is that most of the critically missing bits of functionality are >> actually also available in our JMS client, just not via the JMS API. They're >> usually accessible via some system property or other. > > OK, I get it now. But the naming is more AMQP-like than JMS-like, it seems. > Which is good. > > As long as we separate out the configuration APIs from the messaging APIs, > this approach makes sense to me. > > Jonathan > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
