On Thu, Jul 19, 2012 at 10:59 AM, Gordon Sim <[email protected]> wrote: > 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:
I really like your answers! Sensible and certainly food for thought. > 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. I have long been a supporter of a single broker to better utilize our resources. There is no point having 2 different brokers that does more or less the same thing. However I agree there can be different "classes" of brokers. I will not delve too much into details here, as this not the right forum for that. As Gordon said we should be brave enough to make rational decisions and not let the past constrain us. Besides this will free us to explore new and interesting things. > 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. I think with more time and exposure we will get more clarity here. All though we don't have all the answers yet, we should ensure we continue to have an open & transparent discussion on this, until we get those answers. We also need to ensure we 'take care' of existing users who have invested in these API's. (I believe Gordon made more or less the same point). > 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. The JMS client and the JCA adapter have proven to be an easy entry point for existing users to step into the AMQP world with little impact to their existing applications. We should continue to maintain this advantage !. > 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. Agreed! > 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. Agreed. > 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. +1. Rajith > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
