It would also be good to get agreement on the implementation strategy.
Personally what I believe we would want to do is provide native
Java, Python and C++ 1.0 transports.
Additionally I would like to see that we can use either the native or C++
transports in the Java and Python clients, and then I assume that Ruby,
PHP, C#, etc
will rely on the C++ transport.
This brings the advantage of being able to run pure Java, but also
allows for Java
to use the RDMA transports via C++.
This brings me to also believe that we need to introduce the new
messaging API into
the Java client, and then update the client to layer JMS over that. The
new messaging
API would then be the layer at which we can swap the Java & C++ impls
out under
the new messaging API.
Carl.
On 03/25/2011 08:25 AM, Robert Godfrey wrote:
On 25 March 2011 09:25, Andrew Kennedy<[email protected]>wrote:
On 24 Mar 2011, at 16:45, Rafael Schloming wrote:
On 03/24/2011 11:55 AM, Andrew Stitcher wrote:
On Thu, 2011-03-24 at 16:07 +0100, Robert Godfrey wrote:
...
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...
Actually not necessarily, we already have a superfluous "qpid" directory
at the top level of trunk, so we could introduce "amqp-transport" at
that level if we wanted to.
ie .../asf/qpid/trunk/amqp-transport/...
I'm not necessarily advocating this, but it would avoid a whole lot of
top level moves that might heavily confuse the git mirroring process.
I'd be fine with this option as well. I think the key thing for me is to
maintain the packaging and interface discipline of keeping the transport as
a standalone entity.
We could insert a sub-project at the top level while still maintaining the
existing structure? For example:
.../asf/qpid/trunk/qpid/spec
.../asf/qpid/trunk/qpid/cpp
.../asf/qpid/trunk/qpid/java
.../asf/qpid/trunk/qpid/...
.../asf/qpid/qpid-amqp/trunk/common
.../asf/qpid/qpid-amqp/trunk/cpp
.../asf/qpid/qpid-amqp/trunk/java
.../asf/qpid/qpid-amqp/trunk/...
This is a fairly common idiom. ActiveMQ do this, for instance :
http://svn.apache.org/viewvc/activemq/trunk/
http://svn.apache.org/viewvc/activemq/activemq-protobuf/trunk/
Andrew.
Yeah - I think this is my preferred solution.
To my mind there's probably scope for things that are currently under
"trunk" to migrate to fully blown sub-projects over time, but I think the
immediate next step would be to introduce the
/asf/qpid/transport/[trunk|branches|...]
structure and leave the rest of the project alone for now (especially since
there should be no cross dependencies at this stage.
-- Rob
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
