I'm planning on checking in all the Java code I've been working on for AMQP 1-0 on a branch soon... possibly over the weekend... it's very rough, and I would like to remodel it in terms of the way we've discussed... however the broker changes allow the Qpid Java Broker to do a passable impression of an AMQP 1-0 broker. For a client I've been building something standalone as the current Java client is ... how to put this politely ... not the easiest place to start implementing from :-)
What I'll probably start doing soon is working on a new implementation that follows the style we have discussed below and picking up the things I can re-use from my (essentially) prototyping work. Cheers, Rob On 12 August 2011 16:49, Gordon Sim <[email protected]> wrote: > On 03/24/2011 02:11 PM, Rafael Schloming wrote: > >> I’ve attached a presentation that introduces some of my ideas at a high >> level. I think some people have seen this already, but it's probably a >> good time to share with a broader audience. I’ve also been doing some >> prototyping work exploring an architecture that addresses both of these >> points in the context of a 1-0 implementation. I have a more complete >> python version and a less complete (but improving) C version, both >> currently hosted at github: >> >> https://github.com/rhs/amqp (python prototype) >> https://github.com/rhs/amp (C prototype) >> >> Note that the github location is purely for convenience of sharing and >> backup until I have something that will make sense to introduce to qpid. >> >> As for how to incorporate this into qpid, I think if we want to become a >> ubiquitous protocol implementation, then the transport has to be an >> independently available component that is easily embeddable within third >> party apps that wish to integrate with messaging. As such it needs to >> have as few dependencies as possible and a very narrow and well >> considered set of interfaces. Given this, the natural way to develop >> this would be as an independent sub project within qpid, so that from >> the start we are forced to observe good packaging and dependency >> practices and consider our interfaces carefully. >> > > To start getting some more insight into how this approach might look, I > have been doing some hacking on Rafi's prototype C engine and on an > implementation of the Qpid C++ messaging API over it as well as a first stab > at integrating it with the C++ broker. > > What I've got so far is very rough and very incomplete. However it does > allow the familiar drain/spout examples to be run using the messaging API > against the C++ broker using the latest 1.0 protocol. I've only tested it > against Rafi's python engine so far apart from that. > > This approach looks promising to me. I think it would be great to start > getting some momentum on 1.0 within Qpid over the next couple of months. > Whether we will be in a position to have support of any description in the > 0.14 or whether we simply have some previews available in that time frame, I > think we do want to demonstrate that we are working towards it. > > I plan to work with Rafi to get his engine onto a branch in Qpid's svn and > then (again on a branch) to progress the integration of that into the C++ > components. I'd welcome any input from other interested parties and a branch > seems the simplest way to facilitate that. In the mean time I've attached my > latest patches for qpid svn and the engine itself. > > I'll stress again that these are very much early works in progress. The > engine changes are as yet unreviewed by Rafi and I imagine will undergo some > changes once that review takes place. The integration pieces on the client > and broker are also very incomplete. > > I've also attached some notes on the most obvious missing pieces at > present. There is a lot of work affected by the latest protocol. However we > don't in my view need to tackle it all at once. Hopefully these notes will > be useful in starting some planning discussions. > > I'll send another mail once I get this all on to a branch in svn. This is > just an early notice of that intent. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] >
