On Wed, 2012-07-18 at 20:37 -0400, Carl Trieloff wrote: > > I think the problem is that were we to reform Qpid in today's world, the > > best way to support adoption of AMQP would not be to build yet another > > broker, but rather to build a library that makes it easy to adapt all of > > the many existing brokers to speak AMQP. That is certainly very much > > where proton is aimed, but unless you're prepared to take the view that > > we should dump the brokers and ignore existing Qpid users, it's a > > stretch to say that the de facto mission is no different from the > > original as the de facto mission clearly involves doing something with > > the brokers we've built. > > > I disagree, many project have not tackled the issues many messaging > projects have, and thus it is valuable to have a broker that serves the > user and also pushes on some of the technological boundries. > > Qpid in many cases has introduced many other project to such capabilities.
The value of adding another Broker into the mix is certainly debatable, but that's an orthogonal issue. Even if I were to agree with you that there is value to bulding a fantastic new broker from the ground up to support AMQP 1.0, this would not make sense to mix together into the same project/sub-project with Proton as this new broker is competing with all the existing brokers out there, and Proton is trying to cooperate with them in order to spread AMQP. > > To be clear, I don't believe I ever proposed any sort of change to the > > Qpid mission. My point is that the Proton mission is just different to > > the Qpid mission *of today* (if it were not there would be no point in > > doing it), and depending on what you think the Qpid mission is or should > > be, you may feel it is more or less compatible and/or overlapping with > > the Proton mission. For example, lot's of people think that Qpid is > > about building brokers, and that's pretty much entirely disjoint to what > > Proton is about. > > > Building a broker is part of the qpid mission, but providing protocol > libs, clients libs etc are also. > > technically we could structure the protocol work (proton), client libs, > qmf etc into sub-projects.... The Proton mission isn't just about providing protocol libs, it's about actually getting as many existing apps out there to use them as possible, and mixing those libraries together with competing apps is counter to that goal. Put another way, the mission of competing with other message brokers with an implementation that happens to use AMQP is not compatible with the mission of cooperating with them in an effort to spread AMQP. While these two things could coexist as separate sub projects within an umbrella project, the overall mission of that umbrella project and the governance of the sub projects within the umbrella really needs to be at least a little more explicitly defined and communicated than say e.g. a single project that happens to release multiple artifacts. --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
