Hi Marnie,
QMF evolved from what was originally a mechanism to manage the c++
broker. It is now a much more general-purpose facility for managing
just about anything. There is a growing community of users forming
around QMF including some developers who are submitting patches.
I'm not sure if there is a compelling technical reason to put it in its
own directory except for the fact that most of its components are
independent from the broker and interface to Qpid only through the
public client APIs. From an architectural standpoint, I think it's
beneficial to separate it from the deep internals of Qpid.
Please note that the motivation for doing this now is that there will
shortly be a fairly large, multi-directory commit with new QMF
components (a C++ engine with bindings/wrappers for Python, Ruby, C#,
and C++, plus some Java components). Either way this goes, I need to
find a good place to put the new code.
There are also non-technical/marketing aspects. There are developers
coming to Qpid because they wish to use QMF. But it's hard to find
because it is only an embedded aspect of Qpid. I would like to raise
its profile a bit and putting the code into a separate directory is a
step in that direction. I've also requested an email alias for qmf from
PMC for users who are interested in QMF but not Qpid messaging in general.
It may be that QMF will someday become its own project or sub-project if
interest continues to increase. This separation will make an eventual
spin-off much easier.
Regards and thanks for your interest and input,
-Ted
Marnie McCormack wrote:
Hi Ted,
Why do you need/want separation - what is the goal for moving QMF around ?
It'd be useful to understand the technical drivers for making changes to the
codebase/structure.
Thanks & Regards,
Marnie
On Thu, May 7, 2009 at 3:45 PM, Ted Ross <tross@xxxxxxxxxx> 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?
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:
http://qpid.apache.org
Use/Interact:
mailto:dev-subscribe@xxxxxxxxxxxxxxx