On 03/26/2013 08:06 PM, Rob Godfrey wrote:
I think in general we suffer because we haven't properly thought about what
our "components" are and what it means to be a component. Proton is a
component and has a sensible location in our repo, and its own release
cycle and JIRA project. I tend to think long term other components (or
groups of components) should follow this pattern.
Good points. I personally am not convinced that each component needs its
own JIRA, or its own release cycle. However I do agree that our current
source layout and release artefacts do not align well with logical
components. I would also concede the exact set of components is not as
clear as it needs to be.
So, other than proton, what are the components? I think the key property
of a component is that it is self-contained and independent of any other
particular component. The components that seem most obvious to me at
present are:
* JMS client[1]
* qpid::messaging client in c++
* qpid.messaging client in python[2]
* c++ broker
* java broker
There is probably a component or two among the various management tools.
Some are very toed to one broker, which to some extent violates my rule.
Probably the clearest component here is Fraser's new GUI management
tool, since that can now be used against either broker. The command line
tools for c++ broker[3] are perhaps best viewed as a sub-component of
the c++ broker for now (though some of them may now work against the
java broker when Fraser's adapter is in place).
The various swig and c# wrappers around the qpid::messaging c++ client
are in my view sub components of the c++ client at present.
I am not keen to lump changes to the svn, build and packaging in with
changes to the website. That is exactly why we never make progress
because the scope outgrows the available resource. We can get the
website structure and layout right, map it to the existing 'broken'
structures and then as a separate step(s) tackle any changes to
structure. I don't oppose any changes there, I just don't want the
website update to be dependent on their completion. As Rob said earlier,
having a new website in place for the 0.22 would be really great.
--Gordon.
[1] At present we sort of have two of these, but I think long term there
should be only one, even if it has quite divergent codepaths for
different versions of the protocol. Alternatively we could have one for
AMQP 1.0 and another tucked away somewhere for legacy versions).
[2] Though we need to decide what we are doing for AMQP 1.0 here. If
there is insufficient resource available to convert the native client to
1.0, we could consider the python swig wrapper round the c++ as the
alternative for transition to 1.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
