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.
I would add that at a higher level the best way to get feature choerence is
to use a common set of requirements :-)
I think we need more project co-ordination about i) what we are trying to
achieve in each release and ii) how we go about achieving it. Certainly
there is little visibility on this list as to that. Pulling together the M2
release makes it clearer how disparate the different elements have become.
For M3 I would hope that we set out at the start to define a scope, and try
to pull together those things which we think should be designed jointly by
the C++ and Java communities, and those things which should be completely
language specific.
Personally I think the C++ and Java broker developers can work/design almost
completely independently if they so desire. I think there should be a high
degree of interaction between the client library developers. Contrary to
your experience Alan, I am finding a large number of people who wish to use
more than one client library technology.
It would be good for all of us I think if we all had visibilty on where we
are with each client library, and where we are going. The vote on M2
revealed a great deal uncertainty from the committers as to where the
different client libraries were at.
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.
Agreed... but we should also be careful to properly separate those things
which are separate. The Java Broker and Java Client should be built
separately IMHO. They are each, independently, dependent upon the Java
common library. Always building client and broker together gives one the
impression that they are tied. They should not be. [However it is much
more convenient for me as primarily a Java developer, to always build all
the Java.]
This is a mindset thing. There is (or should not be) a "Java implementation
of Qpid" or a "C++ implementation of Qpid". There is a Java broker, a C++
broker, a Java client, a C++ client, a .NET client, a Python client...
etc...
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.
Hmmm... this Java developer is actually quite keen on shell scripts and not
at all fond of XML... :-) Actually I think configuration is less important
than things like consistent log messages...
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.
And defining what is the scope for a release up front :-)
The code structure we already will serve us well.
We shall see... Ultimately wether the directory structure is
<function>/<language> or <language>/<function> matters little as long as I
can build a C++ client without building the C++ broker....
-- Rob
Cheers
Alan.
