On 07/18/2012 09:43 PM, Rajith Attapattu wrote:
1. What do we want the Qpid brand name to be associated with ? is it
AMQP in general or is it the clients/brokers ?
2. What are we going to do with our current set of brokers ? will they
be there in the future ?
3. What are we going to do with the Messaging API ?
4. What are we going to do with JMS and WCF?
5. What are we going to do with QMF ?
6. What are we going to offer as products/services going forward ?
Good questions! My own answers at present would be:
1. To me Qpid is about AMQP infrastructure at Apache. It is not limited
to clients/brokers. (And in any case proton is evolving to be a client
as well)
2. This is probably the hardest one for me to answer.
As mentioned (more than once, sorry!) I do believe there is a great deal
of value in an AMQP focused broker at Apache, and to me Qpid is
currently the obvious place for that given our charter and our history.
However I think there has long been some concern around the duplication
of effort between the two current Qpid brokers and the confusion that
arises from having them both.
I don't think it is sensible to continue to maintain more than one
broker targeted at the same use cases.
In addition I think the evolution of the protocol has freed us from what
I see as the somewhat flawed model pushed by earlier versions. It also
opens up new possibilities.
So though I don't have any concrete proposal, I think it would make
sense to transition to one broker or to clearly distinguish different
classes of broker if that seems preferable on further analysis. I think
this would be an area where we should see if we can revisit
collaboration with the ActiveMQ project in some guise.
There may emerge some distinct cases that I have heard talked about as
'routers' rather than brokers.
3. This is the second hardest question for me!
I've personally invested a lot of time and effort in the qpid messaging
API. It was specifically geared to transitioning to 1.0. I personally
feel there is much to recommend it still. My desire would be to find a
way for this to 'blend in' with the APIs developing under proton in some
way.
However I agree with Rafi's analysis of the different facets of use; I
find his account of the evolution of proton in this respect compelling.
I think it would be foolish to stick rigidly to the past despite a
deeper, richer understanding of the API space emerging.
I believe that what users really want is not 4 entirely separate APIs,
but something that transitions from one use case to another more
smoothly. Ideally I don't want to have to learn all 4 APIs to see which
one best fits my requirements; ideally I don't want a new requirement in
my system to force me onto an entirely different API.
I think there are still some open questions here. I think the the proton
APIs are very new and may still evolve a little (the engine less so, the
driver and messenger APIs more so). We need more user involvement and
open discussion of options. I hope to have more time in the not too
distant future to collaborate on some of this.
4. I think an open AMQP enabled JMS client is very valuable. I think we
should continue to offer one and it should be based on proton-j.
In theory I think WCF is also useful. In practice we don't at present
have the developer- or user- base to effectively address that in my
view, but if we did I would be very much in favour of it. In other words
I think it is a valuable contribution to our mission if and when we have
the demand and the ability to support that demand.
5. I think a message-based scheme for managing brokers (and indeed
perhaps other AMQP entities) is very valuable. I believe that there is
to me some effort to start standardising such a mechanism on top of AMQP
1.0. In any case QMF as it is needs to adapt to 1.0 and still has a few
warts I'd like to get rid of.
6. As above, there may be such a thing as a 'router', distinct from a
'broker'. At this point that is in my mind at least simply a nice
concept, without sufficient substance but perhaps one for future
thinking/development.
I also think some bridges to other protocols could be useful.
However I think we should try to prioritise and I think as the
foundation of all of this, proton is really the top priority for new
development in my eyes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
