On 20/04/07, Andrew Stitcher <[EMAIL PROTECTED]> wrote:
Speaking from the perspective of the C++ implementation, I'm not sure this would be helpful:
Not necessarily helpful to us developers... true... however in terms of thinking what the actual packages and deliverables from this project are. If we look at this from a "Qpid" perspective, we might want to think about setting requirements for the "client" project and requirements for the "broker" project. At the moment the Java and C++ projects are fairly distinct to the point of being barely interoperable. I think we might be in a better position if we organise ourselves on functional rather than technical lines. At the moment I do wonder what coherence there is to Qpid as a whole... -- Rob 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.
But it is also our way of thinking ... we identify ourselves as working on the "C++" or "Java" (or Python, .NET or whatever) rather than thinking about working on the client or the broker or the management console. Since we are never going to have everyone able to work on all codebases, I think at some level it makes sense to organise our project along a functional split. -- Rob 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 > > >
