On Mon, Jan 21, 2013 at 1:42 PM, Gordon Sim <g...@redhat.com> wrote: > On 01/21/2013 05:22 PM, Rafael Schloming wrote: > >> The users of a piece of software inherently shape its >> direction, and forcing two pieces of software that need to be quite >> independent to have a single user group is going to influence and shape >> that architecture in a way that is contrary to them being independent in >> the first place. >> > > Having a single communication channel for a community is not the same as > forcing independent pieces of software to have a single user group. No one > is 'forcing' anyone into anything. > > I don't believe having more conversations in the wider community need have > any negative impact on the architecture of independent components. > > > I think this is especially concerning because the dev and >> users list are already largely established as the cpp/java broker lists. >> > > I think the lists are as much about the clients (and indeed management > mechanisms) as the brokers. I see them as being places where all the > components have been discussed, in combination with each other or in > conjunction with software outside the project (RabbitMQ, Mule etc etc). > > The conversations evolve as the components evolve. Ultimately people talk > about what they are interested in and what they are using. None of our > lists are particularly high volume at this point, so I am of the opinion > that there is more benefit to sharing a channel of communication than there > is from segmenting it. > > [...] > > It is my >> belief that if AMQP is successful the architectural layer represented by >> the protocol engine + messenger, and the various applications that use it >> (qpid-cpp, qpid-ava, activemq, and more) will ultimately be strongly >> reflected in their own distinct communities and it may well be as strange >> and alien to think of merging the communities/lists as it would be to >> combine the TCP stack/socket API into a single project with the apache web >> server. >> > > Time will tell of course, but I myself take a different view. I think the > analogy is somewhat flawed. > > I think AMQP will have a community of interest around it, a community that > is specifically driven by the vision of interoperability, of composing > systems from many different parts. Not all members of that community will > be interested in the exactly the same set of components of course, but I > think there will be a lot more common interests than your analogy would > suggest. I think there will also be general issues that are relevant to > different components (e.g. global addressing). Having an AMQP focused > community at Apache and having that community discuss various different > components with different architectural relationships seems entirely > natural to me. >
Calling it an analogy is not really being fair. Getting closer to the level of generality I've described has been one of if not the primary design goal behind AMQP 1.0 since it's inception, and the exact parallel I've described has motivated many of its fundamental design choices. You can certainly argue that the design is flawed and it is impossible to implement the architecture in such a decoupled manner, however it's not realistic to simply discount it as a flawed analogy. > > [...] > > Already it's hard to imagine how the details of implementing ssl >> support in proton and the details of implementing a transactional >> persistent message store will significantly benefit from cross >> communication. >> > > In my view that entirely misses the point. Those topics themselves may > seem quite distinct, but there are many people who would be interested in > both of those topics. There are also likely some people who might be > interested in knowing a bit about them and/or contributing to discussions > around them even if they are at present primarily focused on some other > component entirely. > > Clearly users of proton's messenger API may be interested in communicating > with a persistent transactional store. Users of other APIs might be > interested in how the messenger API differs in that use case with whatever > API they use. Implementers of such a store may be interested in proton's > engine API (as well as some other broker/brokers). > > So even with these two distinct topics it seems to me (at the risk of > repeating myself to the point you all stop listening and filter my emails > to /dev/null!) that there are benefits to sharing a communication channel > and at present no real concerns about excessive traffic (at least none so > far expressed). > > I don't think I've missed your point. I agree 100% with you that we need more communication about architecture and how components fit together and that this communication needs to reach a lot of people. Where I disagree with you is that altering the mailing lists will achieve a significant measure of that goal. This communication really needs to be captured in a more permanent form that can be sent (ideally via a small easy to remember URL) to lots of mailing lists, even (perhaps especially) ones outside of qpid. --Rafael
