Rafael Schloming wrote:
Ted Ross wrote:
Rafael Schloming wrote:
Ted Ross wrote:
Good idea Carl,
Here's the current structure:
qpid/cpp/src/qpid/agent - C++ agent library
qpid/cpp/src/qpid/console - C++ console library
qpid/cpp/src/qpid/management - Common files and components for
managing the broker
qpid/python/qmf - Python modules
qpid/ruby/lib/qpid/qmf.rb - Ruby console module
qpid/cpp/managementgen - Code generation tool for C++ agent
qpid/java/management/client/src/main/java/org/apache/qpid/management
- QMF to JMX (QMan)
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.
QMF will be dependent on the public client APIs in qpid (either
installed or built). Of course, there are already dependencies
across top-level directories (cpp, python, ruby, ... depend on specs).
Is this going to be a problem? Is there an alternative that doesn't
have this problem yet gives us some separation?
I think it may be a source of some difficulty. It sort of depends on
what you want to achieve. Do you want qmf to be an integrated part of
the qpid build, or do you want qmf to be an entirely independent build?
Once we establish a stable API/ABI for the messaging clients, there is
no reason for the qmf build to be integrated with the qpid build. Qmf
would only need headers and libraries for the client API to be built.
Qmf will have its own stable API/ABI in multiple languages. I guess one
question we need to answer is whether we want these interfaces to just
be part of Qpid or to be separately deliverable. See my response to Marnie.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
