This topic has been done to death on the list before, but I will try to summarise my position here. For the full debate, consult qpid-dev archives!
> Doesn't that depend to some extent on what they are doing? Yes, which is why 1% might need to use a lower level API. > I write Qpid programs in several languages, and I think fairly directly in > terms of the AMQP model. If I have to use a different model, the JMS model, > to program, I always have to think that much harder. Why the "thou shalt > not" attitude toward programming Java programs directly in the AMQP model? I > would think we would want to support both. Especially since we ship both, > why not let users decide? Having two APIs is not a good idea. It confuses our users - we have already seen some examples of this confusion on the qpid-user list. I strongly believe that we need to make sure that our extended JMS API is as powerful as possible. If not, what is our message to a user who has a JMS application and wants to use some AMQP-specific feature? You need to rewrite your application in our "other" API? JMS, whether we like it or not, is the standard API in Java for messaging - just like JDBC is the standard API for database access. I also strongly believe that having an API that mirrors the protocol is extremely short sighted. This creates all sorts of migration issues as the protocol changes. If you had written an app against a 0-9 API and now want to move to 0-10 you either have to make code changes or get the vendor to make the 0-9 API compatible with a 0-10 broker. The former is likely to alienate users and the latter is likely to be ugly. I understand our Python API mirrors the protocol - what have we done to make the migration to M3 a "zero code change" exercise for our M2.x users? A tutorial is usually something that novice users consult. Using a low-level API is really for more advanced use cases. RG
