On 06/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
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.
Having to make small changes from version to version is not unacceptable. And if we were willing to put the effort in, deprecated compatibility can be achieved for certain things.
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).
Yes, this is the biggest mismatch that I have seen. Promoting the concept of exchange etc to the public API is not a bad thing though and could be used to provide a way forward. We have bent over backwards to make it work inside the JMS Destination model mostly because our users want that (motivated in many cases by a desire by then to use Spring and so on).
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.
I was thinking more of things like the Sybase notification feature. If you do happen to want to use that you can do so within the context of an application that otherwise just uses JDBC (by casting to a SybConnection IIRC).
Exposing an AMQP extension via the JMS API should be demand driven until 1.0
Yes, I agree. We almost certainly have other fish to fry. This is why our extensions have not been particularly aggressive so far.
Writing the JMS layer in terms of an AMQP layer makes sense in terms of maintainability.
Yes, agree here too.
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.
It's forcing users to make that decision to commit to AMQP that bothers me. I think you should be able to choose to use proprietary features in isolated pockets of code within the context of an otherwise standards-based implementation. RG
