On 03/24/2011 11:07 AM, Robert Godfrey wrote:
On 24 March 2011 15:56, Rafael Schloming<[email protected]> wrote:
On 03/24/2011 10:43 AM, Robert Godfrey wrote:
So - obviously we need to hear a few more voices on this... But personally
I'm *really* keen to get the project moving towards AMQP 1-0 ASAP. In my
spare time I've sort of hacked up an AMQP 1-0 Java client, and then
spliced
that onto the Qpid Java Broker... It's not code I would really consider
putting into Qpid, but this (and the code you've got on github) may be
able
to help us bootstrap testing our 1-0 efforts.
If we follow the idea of the common transport, I would guess that the best
way to progress this is probably to create a branch where we can start out
defining and implementing this transport as a standalone entity. It
doesn;t
seem to make sense to me to have this in trunk and tie it into the release
cycles of the current Qpid work...
Thoughts?
For developing the transport itself, I'm not sure it matters much whether
we branch or not if we're treating it as an independent component. Obviously
if we start integrating it into other pieces then a branch for those pieces
would be called for. The release cycle question is certainly interesting. I
agree it shouldn't really be tied to the trunk release in one sense, but I
do think it would be good to have something ready for this year's ApacheCon,
and given that it might make sense to have deliverable milestones that
coincide with the trunk releases purely as a means of focusing progress.
From a theoretical point of view I agree.
Logically we are starting from a clean slate and developing what amounts to
an independent library which we will then, hopefully, make into a dependency
of the rest of qpid...
Branch is probably the wrong name here... but I'm thinking that this doesn't
really fit under the same umbrella as the rest of the components which have
a single release cycle currently. What we possibly want is something that
is in parallel to the existing codebase... repos/asf/qpid/trunk/transport in
parallel to repos/asf/qpid/trunk/qpid would be one way of doing it...
Although looking at other Apache projects it seems like the common way of
doing this is
.../asf/<project>/<component>/trunk or even
.../asf/<project>/<component>/<sub-component>/trunk (see ant, commons,
httpd, etc.)
Though this would obviously require a little more re-organisation for us
all...
I agree we want something parallel. I'm not particularly bothered which
way, I probably have a mild preference for the
<project>/<component>/trunk, but if such a reorg would prove to be a
pain for some reason I wouldn't be particularly bothered by the other way.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
