On 18/09/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
Steven Shaw wrote:
> On 15/09/06, Robert Greig <[EMAIL PROTECTED]> wrote:
>> I think we agree that we need to expose functionality that goes beyond
>> JMS. The question is whether we can do this though extension points to
>> JMS or whether we need a separate API.
>
> Perhaps both.
Support at the 'protocol' level makes it easier for the full flexibility
of AMQP to be exploited in perhaps unanticipated ways.
I can see the utility of providing a way of accessing the protocol at
the lowest level, i.e. sending and receiving protocol frames. I
thought (perhaps incorrectly?) that what was being put forward was an
alternative API that duplicated some functionality already possible
via JMS.
As an example, pulled out the air, imagine a particular use case wants
to set up a single queue with several bindings. Rather that trying to
anticipate all these sorts of usage patterns from the start a more
directly exposed protocol layer would make these easy to compose from
the protocols own building blocks.
Yes, the impossibility of pre-empting every possible use case is a
very fair point. However once a use case is established, adding it
into "extended JMS" would seem feasible to me. (i.e. we have a
protocol level API but only "extended JMS" as the higher level API for
general application developer use).
Is that what you were thinking of?
RG
