On Fri, 2007-04-20 at 15:49 +0100, Robert Godfrey wrote: > 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.
Absolutely agree with the sentiment, but not at all agreed that the breakdown Martin suggests is the way to a achive it. In past lives I have been on two major projects offering equivalent functionaliy in C++ and Java. One had clearly separated C++/Java codebases. The other had a hybrid C++/Java build system split on functional lines (it even built hybrid JNI/C++ code.) The first was *much* more successful at delivering consistency across languages. There are many reasons for that but I can assure you from bitter, bitter personal experience that mixing up languages did _absolutely nothing_ to help make the second project more consistent. So lets think about what we really want in terms of coherence: - interop - feature coherence - consistent "user experience" - coherent packaging All these can be tackled by "meta projects" that combine contributions from each language into the desired result. We need the discipline as developers to insure that we take account of these meta projects when we make changes to any given codebase. It certainly would be a good thing if people work on more than one codebase but I don't think it's productive to force that on people who can't/don't want to. Interop: the *only* way to get interop is to run a daily interop test suite and treat interop failures as trunk failures for *every* language involved. Every language will be required to pass the interop test suite to be considered functional. This is already starting to get underway. Feature coherence: the best way to get feature coherence is to have a comprehensive cross-language feature test suite and require projects to pass it for every feature they claim to support. We already have a pretty decent cross-language broker test suite in the python tests. I anticipate this will develop and there be some synergy with the interop test suite work. Packaging: decide what packages we want and write the infrastructure to assemble them, with each project making its contribution. I suspect packaging along language lines will be what most users want, but there's nothing to preclude packaging along functional lines if people want that too. There's no point trying to organise the code in terms of how we plan to package it because we will certainly want to package it in more than one way. There's also no point in trying to create RPMs with Maven or POMs with Makefiles. Do each task with the most appropriate tools and assemble the result. Consistent "user experience": Usability is more important than consistency. Where consistency and usability conflict, usability should win every time. It's more important to provide the best solution to each environment than a consistent set of solutions that are a bit crappy for one or more environments. For brokers, the users experience is mainly covered by interop & features. Configuration and deployment are certainly areas where we can look at greater alignment, but Unix sysadmins don't like XML, with good reason. Java deployers don't like binaries and shell scripts, with good reason. We should give each what they want. For clients, it is better to provide an excellent API in each langauge than a consistent API that is a bit crap in some or all langauges. Relatively few users work in multiple languages. AMQP has a strong enough conceptual framework to ensure that all clients will be built on the same concepts. Beyond that they should be designed to best suit the programmer of the given language. A large part of CORBA's downfall was the literal translation of interfaces born of C++ into other languages. Java developers _hated_ CORBA APIs, and with good reason. The Java Remote APIS were much better *for Java*. Even as a professed die-hard C++/CORBA bigot, I prefer Java's Remote interfaces when writing Java code because they're so much simpler to use. Splitting every language into micro projects along functional lines does absolutely nothing to address any of the consistency issues, it just makes life a bit harder and slower for all the developers. So lets focus on the real issues: filling out python functional tests, building the interop framework, building a langauge-neutral framework to test clients, better defining what we want to package and writing infrastructure to it and so on. The code structure we already will serve us well. Cheers Alan.
