On 20/04/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
I'd like to know what everyone's opinion was on a reshuffle of the svn
code. I think that we might be able to get away from our 'silos' be
breaking the project by function not implementation. It should allow
us to break the ties between client and broker implementations such
has developed (out of necessity) for the java code base.
The thinking was something along the lines of:
broker
qpidc
qpidj
...
client
qpid.net
qpidc
qpidj
qpidpy
qpidr
common
qpidc
qpidj
management
qpidc
qpidj
qpidjmx
...
spec
gentools
From a practical SVN perspective I'm not sure how this will work.
For example, you frequently want to treat a broker, client and common
for a given language as a single package and then be able to tag and
branch them .With the above would we not have to either grab the whole
thing or create separate branches for each of client/broker/common.
From a practical perspective due to differing resourcing levels on
each language we are going to want to release different languages at
different times. I agree it's not ideal but if we only have a couple
of developers working on .NET then we can't expect it to progress as
rapidly as Java.
Having said that, like everyone else I agree we need to focus more on
interoperability - but this has been tricky to date in no small part
due to the protocol not evolving rapidly enough to support the
features our users demand (e.g.full JMS compatibility). I would hope
and expect that as the protocol matures and stabilises we will be able
to make progress on interop.
RG
