Robert Godfrey wrote:
<snip>
Here's the proposed structure:
qpid/qmf/cpp - C++ implementation of qmf components
qpid/qmf/cpp/bindings - Wrapped bindings to components (Python, Ruby,
C#, WCF, etc.)
qpid/qmf/python - Pure Python implementations (for portability)
qpid/qmf/java - Pure Java implementations
qpid/qmf/windows - Windows implementations
qpid/qmf/tools - CLI utilities, code generators, etc.
qpid/qmf/docs - Documentation
I do not propose to remove anything from the current structure, only to do
new development in the proposed structure. At such a time when it is safe
and non-disruptive to remove code from the old structure, we can do so.
How do you intend to build the code? I presume there are dependencies from
code in qpid/qmf/{cpp,python,java} into qpid/{cpp,python,java}/client. The
current build system is organized around the language division and each
language has a self contained build. This change would seem to disrupt that
model somewhat.
Given our current top level split by language and then by function,
Rafi's proposal seems to make more sense. I've argued before that we
should consider splitting by function at the top level
(common/client/broker/management) and then by language... but having
a mixed model of partly split by function, partly by language at the
top level makes no sense to me at all...
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
Thanks everybody for all the input. There seems to be a consensus (and
I agree) that Rafi's proposed structure is better than mine. I will
proceed using the existing high-level, language-based directories.
-Ted
