On 24 March 2011 15:11, Rafael Schloming <[email protected]> wrote: > On 03/24/2011 09:57 AM, Robert Godfrey wrote: > >> On 24 March 2011 14:47, Rafael Schloming<[email protected]> wrote: >> >> *snip*
> > I agree with your suggested goal. I would actually go slightly farther and > say that pragmatically to succeed we need a much less confusing story for > users than we have right now, so a further goal for the 1-0 work needs to be > to supplant the many obviously separate parts of qpid with a more coherent > suite of artifacts. > > I don't want to bite off more than we can chew - but I certainly agree that we need to make Qpid a much more coherent story than it is now. However, possibly that's a slightly different, though equally important, objective to the one we seem to be discussing now. If we can direct our energies so that the necessary energies we need to expend to get Qpid speaking AMQP 1-0, with the necessary number of client language bindings... and at the same time increase the commonality of API, functionality and configuration for other artefacts (brokers in particular) that would be a spectacular success. I does seem to me though that we should first set our sights firmly on achievable goals... and defining and implementing a "common transport layer" (even if to start off with it is not actually in use in the current artefacts) is a very achievable goal. > As for what I mean by a common transport layer, I think it’s useful to > consider two different dimensions of the problem: firstly, sharing a > transport implementation between different programming models within a > homogenous environment, e.g. a broker and a client, and secondly sharing an > implementation between heterogenous environments, i.e. different languages. > > 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. > > So - as above... this sounds like the beginning of a plan. I really need to have a better idea of the sort of interfaces you are talking about between the different components of your architecture... do you think it would be useful to produce some sort of UML diagram showing how you thing the interfaces between these would look? -- Rob > --Rafael > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] >
