qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Qpid and AMQP 1-0: Plans?
Date Fri, 12 Aug 2011 15:23:14 GMT
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.


On 12 August 2011 16:49, Gordon Sim <gsim@redhat.com> 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:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message