On 06/06/07, Robert Greig <[EMAIL PROTECTED]> wrote:
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?
However thing such as the immediate flag are at the very least
"unstable" right now... and we are seeing problems from our internal
adopters where using our "extensions" make it difficult for them to
upgrade.
The most problematic issue for me is the mismatch between the JMS
notion of Destination and the AMQP notions of exchanges and consumers.
The current implementation jumps through hoops trying to make Topics
and Queues in JMS map to how these are implemented in AMQP... however
other non-standard exchanges (e.g. Headers) don't match well to the
JMS notion (IMHO).
> 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.
I think until the protocol reaches some sort of stability, using
"extensions" carries a risk. Making the extensions available to
end-users should be demand driven right now (again IMHO).
> 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?
JDBC depends on SQL. There is no SQL equivalent in the world of
messaging. Even more, without SQL, relational databases still follow
a reasonably well defined model (tables with columns and rows) - the
same does not hold true for the messaging space.
For me JMS compliance is an absolute must.
Exposing an AMQP extension via the JMS API should be demand driven until 1.0
Writing the JMS layer in terms of an AMQP layer makes sense in terms
of maintainability.
Allowing users who are committed to AMQP (rather than to JMS) to use
an AMQP API does not upset me in the same way it does you.
-- Rob
