On 24 March 2011 15:34, Rafael Schloming <[email protected]> wrote: > On 03/24/2011 10:25 AM, Robert Godfrey wrote: > >> 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: >>>> >>>> >>>> >>> 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? >> > > Yes, I think that would be useful. In fact I've already taken a very brief > look at umlgraph which is purported to be able to automatically produce UML > diagrams from annotated java code. From what I understand it's basically > just a doclet that processes the class hierarchy and produces a graphviz > representation. This might be a good place to start, it would be easy to > throw together a few skeletal java classes that match the interfaces > currently in the python prototype. > > > So - obviously we need to hear a few more voices on this... But personally I'm *really* keen to get the project moving towards AMQP 1-0 ASAP. In my spare time I've sort of hacked up an AMQP 1-0 Java client, and then spliced that onto the Qpid Java Broker... It's not code I would really consider putting into Qpid, but this (and the code you've got on github) may be able to help us bootstrap testing our 1-0 efforts.
If we follow the idea of the common transport, I would guess that the best way to progress this is probably to create a branch where we can start out defining and implementing this transport as a standalone entity. It doesn;t seem to make sense to me to have this in trunk and tie it into the release cycles of the current Qpid work... Thoughts? -- Rob
