Speaking from the perspective of the C++ implementation, I'm not sure this would be helpful:
We've just reorganised the C++ source so that it the file layout matches the namespace layout. As some interfaces are shared between client and broker separating them would cause us a fair bit of pain at build and install time. I do agree that breaking down the silos is a good idea, but I don't think this is the way to do it. Having said that I find that I frequently look at and change the python code, so I think the real cause of the separation is that people don't know/care about that they don't use. Andrew On Fri, 2007-04-20 at 08:39 +0100, Martin Ritchie wrote: > Qpid-ians, > > We've been talking for a while now about interop testing and how the > project members can become quite 'silo-ed' in their language of choice > (I know I've made more than one change to the spec file that broke the > C++, sorry). > > I'd like to know what everyone's opinion was on a reshuffle of the svn > code. I think that we might be able to get away from our 'silos' be > breaking the project by function not implementation. It should allow > us to break the ties between client and broker implementations such > has developed (out of necessity) for the java code base. > > I like to think that in developing 0-10 (and beyond) with the possible > introduction of a common API across all languages (as is being > discussed on another thread) it may make it easier for one developer > to apply the same bugfix/improvement across multiple language > implementations, or at least add in a comment place holder pointing to > the JIRA. > > I know it may be a real pain but as we have a brief break between > deciding what the next AMQP version to push forward with is we have a > rare opportunity to do this setting us up for the future. > > It might even allow us to do some interesting things such as create > shared libraries between languages, like a high speed c++ framing lib > that can be used in the java via JNI. > > The thinking was something along the lines of: > > broker > qpidc > qpidj > ... > client > qpid.net > qpidc > qpidj > qpidpy > qpidr > common > qpidc > qpidj > management > qpidc > qpidj > qpidjmx > ... > spec > gentools > > >
