On 06/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
4) if people want to use advanced AMQP features they are likely writing a new application to interact with other AMQP clients; not using Qpid in a situation where they could replace with another JMS provider.
I think it depends on what those features are. For example, the immediate flag in 0.8 is one small feature that some of our users have found to be useful. The question is: are there real examples where we cannot expose these advanced features using an extended JMS API?
We should have an API which mirrors the AMQP protocol. We should not currently publicise or recommend its use as the protocol is in too great a state of flux
I can see a use for that API mostly as a basis for us building tools and utilities but I don't think we should leave our JMS users high and dry.
For the very reasons that Robert states about protocol flux I would not spend much time trying to expose advanced AMQP features through the JMS API... where is the demand? I would revisit this decision once the protocol has reached v1.0.
I do think that we need to have a better grip on prioritisation - users are more keen right now for us to catch up on other areas. But we should probably answer the question "If we did have an advanced AMQP feature we wanted to expose how would we do it?". Let me ask another question: if you came across a database startup that had some special features only available if you ditched JDBC, would you want to use that product? Would you invest your own money in that company? RG
