On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <g...@redhat.com> wrote: > I think, as has been discussed on this list recently, that getting some > higher level, protocol-independent APIs for those languages that don't > currently have them is a necessary first step and one that will be valuable > regardless.
I think this is going to be really helpful for client applications, most of which don't really want to be tied to protocol versions. The Java client uses JMS for this to an extent, but we still need a way of exposing AMQP specific things in ways that are as version independent as possible (such as the mandatory flag). I've been kicking around the idea of something like this: JMSSession -> AMQSession -> AMQ_[ver]_session With only things that are supported by all version fo AMQP in AMQSession. This does lead to a couple of problems though, such as features that are in all but one version of spec. The other option I was considering was something like JMSSession -> AMQSession -> AMQPre10Session -> AMQ010Session but I think that may be over engineering for the sake of over engineering. > The broker has some limited support for multiple protocols at present, but > they are really the remnants of upgrading from 0-9 'wip' to one version of > 0-10 and then onto the final 0-10 without breaking the build and test > suites. I think some thinking and design around improving that in general > terms would also be a valuable step forwards. The java server supports 0-8 and 0-9, but they're really additional protocol dialects. 0-10 and, in particular, 1-0 have somewhat more substantial semantic differences. In order to properly support them I think they key is to have as modular a server as possible. I've written up some of the improvements to the java server I think should be made here: http://qpid.apache.org/java-broker-modularisation.html (that page needs to be updated a little since some of the works been done in 0.5). The idea is that the core of the server does the basic work of taking a message, putting it on disk, putting on a queue, taking it from a queue and giving it to the client. The details of that, such as how what message goes on what queue before being delivered to a consumer and the protocol used to transfer messages, are implemented by 1 or more plugins which contribute queues, protocol packs, admin wiring etc. There are still some significant details to work out, particularly around administration and translating messages from one protocol version to another. Clearly nirvana here is for a 0-8 client to be able to connect, send a message and have it go to 0-9, 0-10 and 1-0 clients and it Just Works. Similarly, persistence plugins shouldn't have to care about the type of message that they get - they should be able to persist any of them. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
