Robert Godfrey wrote:
On 20 August 2010 15:48, Carl Trieloff <cctriel...@redhat.com> wrote:
I still think it needs debate,
For example, the discussion has been put forward to add in the new API
model in Java between JMS and the transports. This is needed. How does
that relate to this?
This discussing needs to be had a bit more broadly so that all involved in
the client can contribute / agree.
I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
example
on this topic.
(unless it has happened and I missed it, if I see acks then I'll be happy)
Carl.
I want to see the proposal from Andrew before commenting in detail,
but in general this is going on at a lower layer than the API stuff...
here we're considering the interface down to the IO layer. At the
moment this is a bit (no, a *lot*) of a mess, and is completely
different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
There's no real reason for the interface down to the transport from
the different protocol stacks to be different. What I understand
Andrew to be doing is tidying up where Aidan left off in removing
dependencies on particular implementations of an IO layer (e.g. MINA)
from the code, and providing a single interface that can be used by
the current (and future) protocol versions. As part of this I believe
he'll be encapsulating the current MINA code behind the interface so
that it is exposed in a similar way to the IoTransport that was
written as part of the 0-10 work.
The initial driver for this work is to allow for the running of "InVM"
tests on the 0-10 codepath in the same way as they are run for 0-8,
0-9 and 0-9-1 currently. getting these tests running again needs to
be a priority for us in terms of proving the Java Broker for 0-10.
The work is really orthogonal to work on adding the new API to the
Java client and then writing a JMS client library on top of that API.
While I agree that such an approach could greatly simplify the client
- it would involve a major re-write which we would definitely want to
discuss and plan in advance.
I don't think there is any real risk involved in the work Andrew is
discussing, and it will bring significant benefits in terms of
allowing us to use alternative IO layers, and unifying the interface
used underneath 0-10 and the other versions of the protocol.
I agree this is pretty orthogonal to any higher level client refactor,
and getting a common transport interface for 0-8/9/10 makes sense as an
incremental step.
My one reservation is about the OSGi aspect. As a general principal I
would like to keep to an absolute minimum to the dependencies necessary
to run/embed the Java client (or any other clients for that matter). I'd
be interested to hear more about how OSGi is being used, what the
benefit is, and what implications that has for the footprint and
dependencies of the client.
I haven't actually read through the JIRAs yet, so if this is discussed
there already then please just tell me to RTFJ.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
