On Thu, 2012-07-12 at 23:26 +0200, Rob Godfrey wrote: > There are two reasons why I think amqp-libraries@ is strictly superior > to proton@. > > Firstly, while you may consider "proton" as a distinct stream of work, > I'm not sure how that works with something like the messaging API > which fits in with your "quadrant" of APIs, but is clearly not part of > Proton as we know it today.
Fitting into the matrix doesn't say much one way or the other. The matrix is categorizing APIs according to user requirements. Lots of APIs will fit in the matrix, even APIs developed elsewhere which clearly wouldn't belong on any qpid mailing list. The reason that the matrix is relevant to proton is that as the goal of proton is to provide for the easiest possible integration of AMQP 1.0 into the widest possible range of applications, it needs to cater to all four quadrants of that matrix, i.e. make it super easy to integrate with an application or API that uses any one of those models. >From that perspective, I see the future of the messaging API happening in two places. Part of it I think will happen in the proton work stream as I would like to see the future messaging API built on top of proton and I think it should take as much advantage as possible of the architecture proton has for delivering functionality into lots of different languages, e.g. the swig bindings, the python/jython testing infrastructure, etc. This part of it I think really constitutes filling out proton's functionality in the upper right quadrant of the matrix, and I see developers of the future messaging API participating in the proton work stream discussions in the role of proton users. The second part which I see happening outside the proton work stream is really to do with the messaging APIs origins. It's core requirement from the start has been to provide a way for users of the qpid brokers to transition to 1.0 from older protocols. As such there are very likely things that the implementation of the future messaging API will want to do that may well be specific to the qpid brokers, and doing this is perfectly in keeping with that original goal of the messaging APIs, but is not consistent with the goal of proton which requires being broker agnostic. These sorts of things I would expect to be part of the discussion between the future messaging API developers and the future messaging API users, which would really be a conversation that happens on the current qpid lists. > Secondly, as I previously stated, I think that for a new user > searching for information on AMQP libraries, the obvious list to look > for would be "amqp-libraries". The name proton is pretty meaningless > unless you already know it. (There is also perhaps some general value > for us in having the association between "qpid", "amqp" and "library" > become more obvious to search engines). If you look at what "amqp library" pulls up now, it's really difficult to see how a mailing list name will make *any* difference to the results. What we really need is a highly connected web page that makes mention of those words. I also think that particular concern is only relevant for people who already know about amqp, and we actually care about a much broader audience than that. I think we need words like "simple, easy, request/response, pub/sub, messaging, ..." to lead people to us as well, and we're obviously not going to cram all of those into a mailing list name. > In any case I'm not sure that "stream of work" is the right way to > define mailing lists for the user community. Stream of work is a > concept that is meaningful to us, the committers, but a user will be > looking for functionality - which is a more natural definition of a > mailing list. The way that we choose to divide and sub-divide our work > would seem subject to change, what is part of the current "Proton" > stream may not always be so in the future. So to be clear when I talk about "stream of work" I'm not talking about a few people allocated to spend a couple man months on feature X. I'm talking about an ongoing stream of work that will involve a multi year dialog between the developers of said work and its users, and I think the whole point of mailing lists is to facilitate that dialog, so the stream of work is really all that's relevant. I think generally when people join a mailing list it's because they want to talk to a group of people, usually because they have a specific problem they need help with, not because they want to discuss an abstract category of functionality. --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
