On 15/09/06, Robert Greig <[EMAIL PROTECTED]> wrote:
I'm just not convinced of that, at least I think I would need to see a detailed proposal to make that decision. I would also like to understand if it would have any impact on efficiency.
I'd rather see the code running on a branch if someone is prepared to do that.
> This > AMQP-level API may be useful for direct use by other implementors (not > generally end-users) who are building adapters for other middleware > such as SCA or a middleware api adapter at JPMC that I am aware of. Why would it be more useful than an extended JMS API?
I guess if you extend the JMS extentions to cover all the gaps then it will be the same usefulness. However, it may start to look like you have an AMQP API sticking out in your extensions. These extensions may only be used by a select few "middleware" developers (as opposed to application developers). But this is all speculation! What it comes down to for me is that I think it *could* be more elegant to have a amqp api on which to build the jms client.
Would we support it for end users and have to make guarantees about backward compatibility for it?
Maintenance is certainly a downside. I hope the OP is aware of the commitment :) I don't think it would be necessary to guarantee backward compatibility with the amqp api. I see as a layer to build the jms client on, for experiments/tests and for direct middleware adapters. It depends how much of a burden you want it to be. Cheers, Steve.
